rfc2098.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 2098          Toshiba's Router Extension for ATM       February 1997


        IP subnet X           IP subnet Y          IP subnet Z
  <---------------------> <-----------------> <--------------------->

  +-------+ Default  +-------+ Default   +-------+ Default  +-------+
  |       |     -VC  | CSR 1 |     -VC   | CSR 2 |     -VC  |       |
  | Host +=============+   +===============+   +=============+ Host |
  |  X.1 +-------------+++++---------------+++++-------------+  Z.1 |
  |      +-------------+++++---------------+++++-------------+      |
  |      +-------------+++++---------------+++++-------------+      |
  |       |Dedicated |       | Dedicated |       |Dedicated |       |
  +-------+     -VCs +-------+      -VCs +-------+     -VCs +-------+
         <--------------------------------------------------->
                             Bypass-pipe


         Figure 1  Internetworking Architecture based on CSR

3.2  Features

   The main feature of the CSR-based internetworking architecture is the
   same as that of the NHRP-based architecture in the sense that they
   both provide direct ATM level connectivity beyond IP subnet
   boundaries.  There are, however, several notable differences in the
   CSR-based architecture compared with the NHRP-based one as follows.

1) Relationship between IP routing and ATM routing

   In the NHRP model, an egress point of the ATM network is first
   determined in the next hop resolution phase based on IP level routing
   information.  Then the actual route for an ATM-VC to the obtained
   egress point is determined in the ATM connection setup phase based on
   ATM level routing information.  Both kinds of routing information
   would be calculated according to factors such as network topology and
   available bandwidth for the large ATM cloud.  The ATM routing will be
   based on PNNI phase1 [PNNI1.0] while the IP routing will be based on
   OSPF, BGP, IS-IS, etc.  We need to manage two different routing
   protocols over the large ATM cloud until Integtrated-PNNI [IPNNI96]
   which takes both ATM level metric and IP level metric into account
   will be phased in in the future.

   In the CSR model, IP level routing determines an egress point of the
   ATM cloud as well as determines inter-subnet level path to the point
   that shows which CSRs it should pass through.  ATM level routing
   determines an intra-subnet level path for ATM-VCs (both Dedicated-VC
   and Default-VC) only between adjacent nodes (CSRs or ATM-attached
   hosts/routers).  Since the roles of routing are hierarchically
   subdivided into inter-subnet level (router level) and intra-subnet
   level (ATM SW level), ATM routing does not have to operate all over



Katsube, et. al.             Informational                      [Page 7]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


   the ATM cloud but only in individual IP subnets independent from each
   other.  This will decrease the amount of information for ATM routing
   protocol handling.  But an end-to-end ATM path may not be optimal
   compared with the NHRP model since the path should go through routers
   at subnet boundaries in the CSR model.

2) Dynamic routing and redundancy support

   A CSR-based network can dynamically change routes for Bypass-pipes
   when related IP level routing information changes.  Bypass-pipes
   related to the routing changes do not have to be torn down nor
   established from scratch since intermediate CSRs related to IP
   routing changes can follow them and change routes for related
   Bypass-pipes by themselves.

   The same things apply when some error or outage happens in any ATM
   nodes/links/routers on the route of a Bypass-pipe.  CSRs that have
   noticed such errors or outages would change routes for related
   Bypass-pipes by themselves.

3) Interoperability with IP level resource reservation protocols in
   multicast environments

   As current NHRP specification assumes application of NHRP to unicast
   environments only, multicast IP flows should still be carried based
   on a hop-by-hop manner with multicast routers.  In addition,
   realization of IP level resource reservation protocols such as RSVP
   over NHRP environments requires further investigation.

   The CSR-based internetworking architecture which keeps subnet-by-
   subnet internetworking with regard to any control protocol sequence
   can provide multicast Bypass-pipes without requiring any
   modifications in IP multicast over ATM [IPMC96] or multicast routing
   techniques.  In addition, since the CSR can handle RSVP messages
   which are transmitted in a hop-by-hop manner, it can provide Bypass-
   pipes which satisfy QoS requirements by the cooperation of the RSVP
   and the Bypass-pipe control protocol.

4.  Control Architecture for CSR

   Several issues with regard to a control architecture for the CSR are
   discussed in this section.

4.1  Network Reference Model

   In order to help understanding discussions in this section, the
   following network reference model is assumed.  Source hosts S1, S2,
   and destination hosts D1, D2 are attached to Ethernets, while S3 and



Katsube, et. al.             Informational                      [Page 8]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


   D3 are attached to the ATM.  Routers R1 and R5 are attached to
   Ethernets only, while R2, R3 and R4 are attached to the ATM.  The ATM
   datalink for subnet #3 and subnet #4 can either be physically
   separated datalinks or be the same datalink.  In other words, R3 can
   be either one-port or multi-port router.

      Ether    Ether        ATM          ATM        Ether    Ether
        |        |        +-----+      +-----+        |        |
        |        |        |     |      |     |        |        |
    S1--|   S2---|   S3---|     |      |     |---D3   |---D2   |--D1
        |        |        |     |      |     |        |        |
        |---R1---|---R2---|     |--R3--|     |---R4---|---R5---|
        |        |        |     |      |     |        |        |
        |        |        +-----+      +-----+        |        |
     subnet   subnet      subnet       subnet      subnet   subnet
       #1       #2          #3           #4          #5       #6


                   Figure 2  Network Reference Model

   Bypass-pipes can be configured [S3 or R2]-->R3-->[D3 or R4].  That
   means that S3, D3, R2, R3 and R4 need to speak Bypass-pipe control
   protocol, and means that R3 needs to be the CSR.  We use term
   "Bypass-capable nodes" for hosts/routers which can speak Bypass-pipe
   control protocol but are not necessarily CSRs.

   As shown in this reference model, Bypass-pipe can be configured from
   host to host (S3-->R3-->D3), router to host (R2-->R3-->D3), host to
   router (S3-->R3-->R4), and router to router (R2-->R3-->R4).

4.2  Possible Use of Bypass-pipe

   Possible use (or purposes) of Bypass-pipe provided by CSRs, in other
   words, possible triggers that initiate Bypass-pipe setup procedure,
   is discussed in this subsection.

   Following two purposes for Bypass-pipe setup are assumed at present;

a) Provision of low latency path

   This indicates cases in which end hosts or routers initiate a
   Bypass-pipe setup procedure when they will transmit large amount of
   datagrams toward a specific destination.  For instance,

   - End hosts or routers initiate Bypass-pipe setup procedures based
     on the measurement of IP datagrams transmitted toward a certain
     destination.




Katsube, et. al.             Informational                      [Page 9]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


   - End hosts or routers initiate Bypass-pipe setup procedures when
     it detects datagrams with certain higher layer protocols such as
     ftp, nntp, http, etc.

   Other triggers may be possible depending on the policy in each
   network.  In any case, the purpose of Bypass-pipe setup in each of
   these cases is to reduce IP processing burden at intermediate routers
   as well as to provide a communication path with low latency for burst
   data transfer, rather than to provide end host applications with
   specific bandwidth/QoS.

   There would be no rule for determining bandwidth for such kinds of
   Bypass-pipes since no explicit information about bandwidth/QoS
   requirement by end hosts is available without IP-level resource
   reservation protocols such as RSVP.  Using UBR VCs as components of
   the Bypass-pipe would be the easiest choice although there is no
   guarantees for cell loss quality, while using other services such as
   CBR/VBR/ABR with an adequate parameter tuning would be possible.

b) Provision of specific bandwidth/QoS requested by hosts

   This indicates cases in which routers or end hosts initiate a
   Bypass-pipe setup procedure by triggers related to IP-level
   bandwidth/QoS request from end hosts.  The "resource management
   entity" in the host or router, which has received bandwidth/QoS
   requests from applications or adjacent nodes may choose to
   accommodate the requested IP flow to an existing VC or choose to
   allocate a new Dedicated-VC for the requested IP flow.  Selecting the
   latter choice at each router can correspond to the trigger for
   constituting a Bypass-pipe.  When both an incoming VC and an outgoing
   VC (or VCs) are dedicated to the same IP flow(s), those VCs can be
   concatenated at the CSR (ATM cut-through) to constitute a Bypass-
   pipe.  Bandwidth for the Bypass-pipe (namely, individual VCs
   constituting the Bypass-pipe) in this case would be determined based
   on the bandwidth/QoS requirements by the end host which is conveyed
   by, e.g., RSVP messages.  The ATM service classes; e.g., CBR/VBR/ABR;
   that would be selected depends on the IP-level service classes
   requested by the end hosts.

   Bypass-pipe provision for the purpose of b) will surely be beneficial
   in the near future when related IP-level resource reservation
   protocol will become available as well as when definitions of
   individual service classes and flow specs offered to applications
   become clear.  On the other hand, Bypass-pipe setup for the purpose
   of a) may be beneficial right now since it does not require
   availability of IP-level resource reservation protocols.  In that
   sense, a) can be regarded as a kind of short-term use while b) is a
   long-term use.



Katsube, et. al.             Informational                     [Page 10]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


4.3  Variations of Bypass-pipe Control Architecture

   A number of variations regarding Bypass-pipe control architecture are
   introduced.  Items which are related to architectural variations are;

    o Ways of providing Dedicated-VCs

    o Channels for Bypass-pipe control message transfer

    o Bypass-pipe control procedures

   Each of these items are discussed below.

4.3.1  Ways of Providing Dedicated-VCs

   There are roughly three alternatives regarding the way of providing
   Dedicated-VCs in individual IP subnets as components of a Bypass-
   pipe.

a) On-demand SVC setup

   Dedicated-VCs are set up in individual IP subnets each time you want
   to set up a Bypass-pipe through the ATM signaling procedure.

b) Picking up one from a bunch of (semi-)PVCs

   Several VCs are set up beforehand between CSR and CSR, or CSR and
   other ATM-attached nodes (hosts/router) in each IP subnet. Unused VC
   is picked up as a Dedicated-VC from these PVCs in each IP subnet when
   a Bypass-pipe is set up.

c) Picking up one VCI in PVP/SVP

   PVPs or SVPs are set up between CSR and CSR, or CSR and other ATM-
   attached nodes (hosts/routers) in each IP subnet.  PVPs would be set
   up as a router/host initialization procedure, while SVPs, on the
   other hand, would be set up through ATM signaling when the first VC
   (either Default- or Dedicated-) setup request is initiated by either
   of some peer nodes.  Then, Unused VCI value is picked up as a
   Dedicated-VC in the PVP/SVP in each IP subnet when a Bypass-pipe is
   set up.  The SVP can be released through ATM signaling when no VCI
   value is in active state.

   The best choice will be a) with regard to efficient network resource
   usage.  However, you may go through three steps, ATMARP (for unicast
   [RFC1577] or multicast [IPMC96] in each IP subnet), SVC setup (in
   each IP subnet) and exchange of Bypass-pipe control message in this
   case.  Whether a) is practical choice or not will depend on whether



Katsube, et. al.             Informational                     [Page 11]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


   you can allow larger Bypass-pipe setup time due to three-step
   procedure mentioned above, or whether you can send datagrams over
   Default-VCs in a hop-by-hop manner while waiting for the Bypass-pipe
   set up.

   In the case of b) or c), the issue of Bypass-pipe setup time will be
   improved since SVC setup step can be skipped.  In b), each node (CSR
   or ATM-attached host/router) should specify some traffic descriptors
   even for unused VCs, and the ATM datalink should reserve its desired
   resource (such as VCI value and bandwidth) for them.  In addition,
   the ATM datalink may have to carry out UPC functions for those unused
   VCs.  Such burden would be reduced when you use UBR-PVCs and set peak
   cell rate for each of them equal to link rate, but bandwidth/QoS for
   the Bypass-pipe is not provided in this case.  In c), on the other
   hand, traffic descriptors which should be specified by each node for
   the ATM datalink is not each VC's but VP's only.  Resource
   reservations for individual VCs will be carried out not as a
   functionality of the ATM datalink but of each CSR or ATM-attached
   host/router if necessary.  A functionality which need to be provided
   by the ATM datalink is control of VPs' bandwidth only such as UPC and
   dynamic bandwidth negotiation if it would be widely available.

4.3.2  Channels for Bypass-pipe Control Message Transfer

   There are several alternatives regarding the channels for managing
   (setting up, releasing, and possibly changing the route of) a
   Bypass-pipe.  This subsection explains these alternatives and
   discusses their properties.

   Three alternatives are discussed, Inband control message, Outband
   control message, and use of ATM signaling.

i) Inband Control Message

   When setting up a Bypass-pipe, control messages are transmitted over
   a Dedicated-VC which will eventually be used as a component of the
   Bypass-pipe.  These messages are handled at each CSR, and similar
   messages are transmitted to the next-hop node over a Dedicated-VC
   along the selected route (based on IP routing table).  Unlike outband
   message protocol described in ii), each message does not have to
   indicate a Dedicated-VC which will be used since the message itself
   is carried over "that" VC.

   The inband control message can be either "datagram dedicated for
   Bypass-pipe control" or "actual IP datagram" sent by user
   application.  Actual IP datagrams can be transmitted over Bypass-pipe
   after it has been set up in the former case.  In the latter case, on
   the other hand, the first (or several) IP datagram(s) received from



Katsube, et. al.             Informational                     [Page 12]

RFC 2098          Toshiba's Router Extension for ATM       February 1997