doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc2379.txt b/doc/rfc/rfc2379.txt
new file mode 100644
index 0000000..fb92d84
--- /dev/null
+++ b/doc/rfc/rfc2379.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                          L. Berger
+Request for Comments: 2379                                  FORE Systems
+BCP: 24                                                      August 1998
+Category: Best Current Practice
+
+
+                RSVP over ATM Implementation Guidelines
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Abstract
+
+   This memo presents specific implementation guidelines for running
+   RSVP over ATM switched virtual circuits (SVCs).  The general problem
+   is discussed in [6].  Implementation requirements are discussed in
+   [2].  Integrated Services to ATM service mappings are covered in [3].
+   The full set of documents present the background and information
+   needed to implement Integrated Services and RSVP over ATM.
+
+1. Introduction
+
+   This memo discusses running IP over ATM in an environment where SVCs
+   are used to support QoS flows and RSVP is used as the internet level
+   QoS signaling protocol.  It applies when using CLIP/ION, LANE2.0 and
+   MPOA methods for supporting IP over ATM.  The general issues related
+   to running RSVP[4] over ATM have been covered in several papers
+   including [6] and other earlier work.  This document is intended as a
+   companion to [6,2] and as a guide to implementers.  The reader should
+   be familiar with both documents.
+
+   This document provides a recommended set of functionality for
+   implementations using ATM UNI3.x and 4.0, while allowing for more
+   sophisticated approaches.  We expect some vendors to additionally
+   provide some of the more sophisticated approaches described in [6],
+   and some networks to only make use of such approaches.  The
+   recommended set of functionality is defined to ensure predictability
+   and interoperability between different implementations.  Requirements
+   for RSVP over ATM implementations are provided in [2].
+
+
+
+
+
+Berger                   Best Current Practice                  [Page 1]
+
+RFC 2379        RSVP over ATM Implementation Guidelines      August 1998
+
+
+   This document uses the same terms and assumption stated in [2].
+   Additionally, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
+   "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in RFC
+   2119 [5].
+
+2. Implementation Recommendations
+
+   This section provides implementation guidelines for implementation of
+   RSVP over ATM.  Several recommendations are common for all, RSVP
+   sessions, both unicast and multicast.  There are also recommendations
+   that are unique to unicast and multicast session types.
+
+2.1 RSVP Message VC Usage
+
+   The general issues related to which VC should be used for RSVP
+   messages is covered in [6]. It discussed several implementation
+   options including: mixed control and data, single control VC per
+   session,  single control VC multiplexed among sessions, and multiple
+   VCs multiplexed among sessions.  QoS for control VCs was also
+   discussed.  The general discussion is not repeated here and [6]
+   should be reviewed for detailed information.
+
+   RSVP over ATM implementations SHOULD send RSVP control (messages)
+   over the best effort data path, see figure 1.  It is permissible to
+   allow a user to override this behavior.  The stated approach
+   minimizes VC requirements since the best effort data path will need
+   to exist in order for RSVP sessions to be established and in order
+   for RSVP reservations to be initiated.  The specific best effort
+   paths that will be used by RSVP are: for unicast, the same VC used to
+   reach the unicast destination; and for multicast, the same VC that is
+   used for best effort traffic destined to the IP multicast group.
+   Note that for multicast there may be another best effort VC that is
+   used to carry session data traffic, i.e., for data that is both in
+   the multicast group and matching a sessions protocol and port.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger                   Best Current Practice                  [Page 2]
+
+RFC 2379        RSVP over ATM Implementation Guidelines      August 1998
+
+
+                            Data Flow ==========>
+
+                                   QoS VCs
+                    +-----+    -------------->   +----+
+                    |     |  -------------->     |    |
+                    | Src |                      | R1 |
+                    |     |   Best Effort VC(s)  |    |
+                    +-----+  <-----------------> +----+
+                                 /\
+                                 ||
+                                 ||
+                             RSVP Control
+                               Messages
+
+                  Figure 1: RSVP Control Message VC Usage
+
+
+   The disadvantage of this approach is that best effort VCs may not
+   provide the reliability that RSVP needs.  However the best effort
+   path is expected to satisfy RSVP reliability requirements in most
+   networks. Especially since RSVP allows for a certain amount of packet
+   loss without any loss of state synchronization.
+
+2.2 Aggregation
+
+   As discussed in [6], data associated with multiple RSVP sessions can
+   be sent using the same shared VCs. Implementation of such
+   "aggregation" models is still a matter for research.  Therefore, RSVP
+   over ATM implementations SHOULD use independent VCs for each RSVP
+   reservation.
+
+2.3 Short-Cuts
+
+   Short-cuts allow ATM attached routers and hosts to directly establish
+   point-to-point VCs across LIS boundaries, i.e., the VC end-points are
+   on different IP subnets. Short-cut support for unicast traffic has
+   been defined in [7] and [1].  The ability for short-cuts and RSVP to
+   interoperate has been raised as a general question.  The area of
+   concern is the ability to handle asymmetric short-cuts.  Specifically
+   how RSVP can handle the case where a downstream short-cut may not
+   have a matching upstream short-cut.  In this case, which is shown in
+   figure 2, PATH and RESV messages following different paths.
+
+
+
+
+
+
+
+
+
+Berger                   Best Current Practice                  [Page 3]
+
+RFC 2379        RSVP over ATM Implementation Guidelines      August 1998
+
+
+                       ______
+                      /      \
+           +-------- / Router \ <-------+
+           |         \        /         |   <....... RESVs Follow
+           |          \______/          |            Hop-by-hop Path
+           |                            |
+           |                            |
+           V           QoS VCs          |
+        +-----+    ==============>   +----+
+        |     |  ==============>     |    |
+        | Src |                      | R1 |
+        |     |   Best Effort VC(s)  |    |
+        +-----+  <=================> +----+
+
+                     /\
+                     ::                        Data Paths:
+                     ::                        ----> Hop-by-hop (routed)
+               PATHs and Data                  ====> Short-cut
+              Follow Short-cut
+                     Path
+
+      Figure 2: Asymmetric RSVP Message Forwarding With ATM Short-Cuts
+
+
+   Examination of RSVP shows that the protocol already includes
+   mechanisms that allows support of the asymmetric paths.  The
+   mechanism is the same one used to support RESV messages arriving at
+   the wrong router and the wrong interface. RSVP messages are only
+   processed when they arrive at the proper interface. When messages
+   arrive on the wrong interface, they are forwarded by RSVP.  The
+   proper interface is indicated in the NHOP object of the message. So,
+   existing RSVP mechanisms will support the asymmetric paths that can
+   occur when using short-cuts.
+
+   The short-cut model of VC establishment still poses several issues
+   when running with RSVP. The major issues are dealing with established
+   best effort short-cuts, when to establish short-cuts, and QoS only
+   short-cuts. These issues will need to be addressed by RSVP
+   implementations.
+
+   The key issue to be addressed by RSVP over ATM implementations is
+   when to establish a short-cut for a QoS data flow.  RSVP over ATM
+   implementations SHOULD simply follow best effort traffic. When a
+   short-cut has been established for best effort traffic to a
+   destination or next-hop, that same end-point SHOULD be used when
+   setting up RSVP triggered VCs for QoS traffic to the same destination
+   or next-hop. This will happen naturally when PATH messages are
+   forwarded over the best effort short-cut.  Note that in this
+
+
+
+Berger                   Best Current Practice                  [Page 4]
+
+RFC 2379        RSVP over ATM Implementation Guidelines      August 1998
+
+
+   approach, when best effort short-cuts are never established, RSVP
+   triggered QoS short-cuts will also never be established.
+
+2.4 Data VC Management for Heterogeneous Sessions
+
+   Heterogeneous sessions can only occur with multicast RSVP sessions.
+   The issues relating to data VC management of heterogeneous sessions
+   are covered in detail in [6] and are not repeated in this document.
+   In summary, heterogeneity occurs when receivers request different
+   levels of QoS within a single session and also when some receivers do
+   not request any QoS.  Both types of heterogeneity are shown in figure
+   3.
+
+                                    +----+
+                           +------> | R1 |
+                           |        +----+
+                           |
+                           |        +----+
+              +-----+ -----+   +--> | R2 |
+              |     | ---------+    +----+        Receiver Request Types:
+              | Src |                             ---->  QoS 1 and QoS 2
+              |     | .........+    +----+        ....>  Best-Effort
+              +-----+ .....+   +..> | R3 |
+                           :        +----+
+                       /\  :
+                       ||  :        +----+
+                       ||  +......> | R4 |
+                       ||           +----+
+                     Single
+                  IP Mulicast
+                     Group
+
+                    Figure 3: Types of Multicast Receivers
+
+   [6] provides four models for dealing with heterogeneity: full
+   heterogeneity,  limited heterogeneity, homogeneous, and modified
+   homogeneous models.  The key issue to be addressed by an
+   implementation is providing requested QoS downstream. One of, or some
+   combination of, the discussed models [6] may be used to provide the
+   requested QoS.  Unfortunately, none of the described models is the
+   right answer for all cases.  For some networks, e.g.  public WANs, it
+   is likely that the limited heterogeneous model or a hybrid limited-
+   full heterogeneous model will be desired.  In other networks, e.g.
+   LANs, it is likely that a the modified homogeneous model will be
+   desired.
+
+
+
+
+
+
+Berger                   Best Current Practice                  [Page 5]
+
+RFC 2379        RSVP over ATM Implementation Guidelines      August 1998
+
+
+   Since there is not one model that satisfies all cases,
+   implementations SHOULD implement one of either the limited
+   heterogeneity model or the modified homogeneous model.
+   Implementations SHOULD support both approaches and provide the
+   ability to select which method is actually used, but are not required
+   to do so.
+
+3. Security Considerations
+
+   The same considerations stated in [4] and [8] apply to this document.
+   There are no additional security issues raised in this document.
+
+4. Acknowledgments
+
+   This work is based on earlier drafts and comments from the ISSLL
+   working group.  The author would like to acknowledge their
+   contribution, most notably Steve Berson who coauthored one of the
+   drafts.
+
+5. Author's Address
+
+   Lou Berger
+   FORE Systems
+   1595 Spring Hill Road
+   5th Floor
+   Vienna, VA 22182
+
+   Phone: +1 703-245-4527
+   EMail: lberger@fore.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger                   Best Current Practice                  [Page 6]
+
+RFC 2379        RSVP over ATM Implementation Guidelines      August 1998
+
+
+REFERENCES
+
+   [1] The ATM Forum, "MPOA Baseline Version 1", May 1997.
+
+   [2] Berger, L., "RSVP over ATM Implementation Requirements",
+       RFC 2380, August 1998.
+
+   [3] Borden, M., and M. Garrett, "Interoperation of Controlled-Load
+       and Guaranteed-Service with ATM", RFC 2381, August 1998.
+
+   [4] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
+       "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
+       Specification", RFC 2205, September 1997.
+
+   [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Levels", BCP 14, RFC 2119, March 1997.
+
+   [6] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M., and
+       J. Krawczyk, "A Framework for Integrated Services and RSVP over
+       ATM", RFC 2382, August 1998.
+
+   [7] Luciani, J., Katz, D., Piscitello, D., and B. Cole, "NBMA Next
+       Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
+
+   [8] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E., and
+       A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755,
+       February 1995.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger                   Best Current Practice                  [Page 7]
+
+RFC 2379        RSVP over ATM Implementation Guidelines      August 1998
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger                   Best Current Practice                  [Page 8]
+