rfc2098.txt

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

   an unused Dedicated-VC are analyzed at IP level and transmitted
   toward adequate next hop over an unused Dedicated-VC.  Then incoming
   Dedicated-VC and outgoing Dedicated-VC are concatenated to construct
   a Bypass-pipe.

   In inband control, Bypass-pipe control messages transmitted after a
   Bypass-pipe has been set up cannot be identified at intermediate CSRs
   since those messages are forwarded at cell level there.  As a
   possible solution for this issue, intermediate CSRs can identify
   Bypass-pipe control messages by marking cell headers, e.g., PTI bit
   which indicates F5 OAM cell.  With regard to Bypass-pipe release,
   explicit release message may not be necessary if individual CSRs
   administer the amount of traffic over each Dedicated-VC and deletes
   concatenation information for an inactive Bypass-pipe with their own
   decision.

ii) Outband Control Message

   When a Bypass-pipe is set up or released, control messages are
   transmitted over VCs which are different from Dedicated-VCs used as
   components of the Bypass-pipe.  Unlike inband message protocol
   described in i), each message has to indicate which Dedicated-VCs the
   message would like to control.  Therefore, an identifier that
   uniquely discriminates a VC, which is not a VPI/VCI that is not
   identical at both endpoints of the VC, need to be defined and be
   given at VC initiation phase.  However, an issue of control message
   transmission after a Bypass-pipe has been set up in inband case does
   not exist.

   Four alternatives are possible regarding how to convey Bypass-pipe
   control messages hop-by-hop over ATM datalink networks.

   1) Defines VC for Bypass-pipe control messages only.

   2) Uses Default-VC and discriminates Bypass-pipe control messages
      from user datagrams by an LLC/SANP value in RFC1483 encapsulation.

   3) Uses Default-VC and discriminates Bypass-pipe control messages
      from user datagrams by a protocol field value in IP header.

   4) Uses Default-VC and discriminates Bypass-pipe control messages
      from user datagrams by a port ID in the UDP frame.

   When we take into account interoperability with Bypass-incapable
   routers, 1) will not be a good choice.  Whether we select 2) or 3) 4)
   depends on whether we should consider multiprotocol rather than IP
   only.




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


   In the case of IP multicast, point-to-multipoint VCs in individual
   subnets are concatenated at CSRs consecutively in order to constitute
   end-to-end multicast tree.  Above four alternatives may require the
   same number of point-to-multipoint Defalut-VCs as the number of
   requested point-to-multipoint Dedicated-VCs in multicast case.  The
   fifth alternative which can reduce the necessary number of VCs to
   convey control messages in a multicast environment is;

   5) Defines point-to-multipoint VC whose leaves are members of
      multicast group 224.0.0.1.  All nodes which are members of at
      least one of active multicast group would become leaves of this
      point-to-multipoint VC.

   Each upstream node may become a root of the point-to-multipoint VC,
   or a sort of multicast server to which each upstream node transmits
   cells over a point-to-point VC may become a root of that.  In any
   case, Bypass-pipe control messages for every multicast group are
   transmitted to all nodes which are members of either of the group.
   When a downstream node has received control messages which are not
   related to a multicast group it belongs, it should discard them by
   referring to a destination group address on their IP header.
   Donwstream node would still need to use point-to-point VC to send
   control messages toward upstream.

iii)  Use of ATM Signaling Message

   Supposing that ATM signaling messages can convey IP addresses (and
   possibly port IDs) of source and destination, it may be possible that
   ATM signaling messages be used as Bypass-pipe control messages also.
   In that case, an ATM connection setup message indicates a setup of a
   Dedicated-VC to an ATM address of a desirable next-hop IP node, and
   also indicates a setup of a Bypass-pipe to an IP address (and
   possibly port ID) of a target destination node.  Information elements
   for the Dedicated-VC setup (ATM address of a next-hop node,
   bandwidth, QoS, etc.) are handled at ATM nodes, while information
   elements for the Bypass-pipe setup (source and destination IP
   addresses, possibly their port IDs, or flow label for IPv6, etc.) are
   transparently transferred to the next-hop IP node.  The next-hop IP
   node accepts Dedicated-VC setup and handles such IP level information
   elements.

   ATM signaling messages can be transferred from receiver to sender as
   well as sender to receiver when you set zero Forward Cell Rate and
   non-zero Backward Cell Rate as an ATM traffic descriptor information
   element in unicast case, or when Leaf Initiated Join capabilities
   will become available in multicast case.





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


   Issues in this method are,

    - Information elements which specify IP level (and port level)
      information need to be defined, e.g., B-HLI or B-UUI, as an ATM
      signaling specification.

    - It would be difficult to support soft-state Bypass-pipe control
      which transmits control messages periodically since ATM signaling
      is a hard-state protocol.

4.3.3  Bypass-pipe Control Procedures

   This subsection discusses several items with regard to actual
   procedures for Bypass-pipe control.

a) Distributed trigger vs. Centralized (restricted) trigger

   The first item to be discussed is whether the functionality of
   detecting a trigger of Dedicated-VC/Bypass-pipe control is
   distributed to all the nodes (including CSRs and hosts/edge devices)
   or restricted to specific nodes.

   In the case of the distributed trigger, every node is regarded as
   having a capability of detecting a trigger of Bypass-pipe setup or
   termination.  For example, every node detects datagrams for ftp, and
   sets up (or fetches) a Dedicated-VC individually to construct a
   Bypass-pipe.  After setting up or fetching the Dedicated-VCs,
   messages which informs (or requests) the transmission of the IP flow
   over the Dedicated-VC are exchanged between adjacent nodes.  That
   enables peer nodes to share the same knowledge about the mapping
   relationship between the IP flow and the Dedicated-VC.  There is no
   end-to-end message transmission in the Bypass-pipe control procedure
   itself, but transmission between adjacent nodes only.

   In the case of the centralized (or restricted) trigger, capability of
   detecting a trigger of Bypass-pipe setup or termination is restricted
   to nodes which are located at "the boundary of the CSR-cloud".  The
   boundary of the CSR-cloud signifies, for individual IP flows, the
   node which is the first-hop or the last-hop CSR-capable node.  For
   example, a node which detects datagrams for ftp can initiate Bypass-
   pipe setup procedure only when its previous hop is non-ATM or CSR-
   incapable.  In this case, Bypass-pipe control messages are originated
   at the boundary of the CSR-cloud, and forwarded hop-by-hop toward
   another side of the boundary, which is similar to ATM signaling
   messages.  The semantics of the messages may be the request of end-
   to-end Bypass-pipe setup as well as notification or request of
   mapping relationship between the IP flow and the Dedicated-VC.




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


b) Upstream-initiated control vs. Downstream-initiated control

   The second item to be discussed is whether the setup of a Dedicated-
   VC and the control procedure for constructing a Bypass-pipe are
   initiated by upstream side or downstream side.

   In the case of the upstream-initiated control, the upstream node
   takes the initiative when setting up a Dedicated-VC for a specific IP
   flow and creating the mapping relationship between the IP flow and
   the Dedicated-VC.  For example, a CSR which detects datagrams for ftp
   sets up (or fetches) a Dedicated-VC toward its downstream neighbor
   and notifies its downstream neighbor that it will transmit a specific
   IP flow over the Dedicated-VC.  This means that the downstream node
   is requested to receive datagrams from the Dedicated-VC.

   In the case of the downstream-initiated control, the downstream node
   takes the initiative when setting up a Dedicated-VC for a specific IP
   flow and creating the mapping relationship between the IP flow and
   the Dedicated-VC.  For example, a CSR which detects datagrams for ftp
   sets up (or fetches) a Dedicated-VC toward its upstream neighbor and
   requests its upstream neighbor to transmit a specific IP flow over
   the Dedicated-VC.  This means that the upstream node is requested to
   transmit the IP flow over the Dedicated-VC.

c) Hard-state management vs. Soft-state management

   The third item to be discussed is whether the control (setup,
   maintain, and release) of the Bypass-pipe is based on hard-state or
   soft-state.

   In hard-state management, individual nodes transmit Bypass-pipe
   control messages only when they want to notify or request any change
   in their neighbors' state.  They should wait for an acknowledgement
   of the message before they change their internal state.  For example,
   after setting up a Bypass-pipe, it is maintained until either of a
   peer nodes transmits a message to release the Bypass-pipe.

   In soft-state management, individual nodes periodically transmit
   Bypass-pipe control messages in order to maintain their neighbors'
   state.  They do not have to wait for an acknowledgement of the
   message before they changes its internal state.  For example, even
   after setting up a Bypass-pipe, either of a peer nodes is required to
   periodically transmit refresh messages to its neighbor in order to
   maintain the Bypass-pipe.

5.  Security Considerations

   Security issues are not discussed in this memo.



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


6.  Summary

   Basic concept of Cell Switch Router (CSR) are clarified and control
   architecture for CSR is discussed.  A number of methods to control
   Bypass-pipe will be possible each of which has its own advantages and
   disadvantages.  Further investigation and discussion will be
   necessary to design control protocol which may depend on the
   requirements by users.

7.  References

   [IPMC96] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based
   ATM Networks", RFC 2022, November 1996.

   [ATM3.1] The ATM-Forum, "ATM User-Network Interface Specification,
   v.3.1", Sept. 1994.

   [RSVP13] Braden, R., et al., "Resource ReSerVation Protocol (RSVP),
   Version 1 Functional Specification", Work in Progress.

   [IPNNI96] R. Callon, et al., "Issues and Approaches for Integrated
   PNNI", The ATM Forum Contribution No. 96-0355, April 1996.

   [NHRP09]  Luciani, J., et al., "NBMA Next Hop Resolution Protocol
   (NHRP)", Work in Progress.

   [PNNI1.0] The ATM-Forum, "P-NNI Specification Version 1.0", March
   1996.

   [RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM
   Adaptation Layer 5", RFC 1483, July 1993.

   [RFC1577] Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
   October 1993.

   [RFC1819] Delgrossi, L, and L. Berger, "Internet STream Protocol
   Version 2 (STII) Protocol Specification Version ST2+", RFC 1819,
   August 1995.













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


8.  Authors' Addresses

   Yasuhiro Katsube
   R&D Center, Toshiba
   1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
   Japan
   Phone : [phone]
   EMail : [e-mail]

   Ken-ichi Nagami
   R&D Center, Toshiba
   1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
   Japan
   Phone : [phone]
   EMail : [e-mail]

   Hiroshi Esaki
   R&D Center, Toshiba
   1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
   Japan
   Phone : [phone]
   EMail : [e-mail]





























Katsube, et. al.             Informational                     [Page 18]