summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3496.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3496.txt')
-rw-r--r--doc/rfc/rfc3496.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc3496.txt b/doc/rfc/rfc3496.txt
new file mode 100644
index 0000000..781679d
--- /dev/null
+++ b/doc/rfc/rfc3496.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group A. G. Malis
+Request for Comments: 3496 T. Hsiao
+Category: Informational Vivace Networks
+ March 2003
+
+
+ Protocol Extension for Support of Asynchronous Transfer Mode (ATM)
+ Service Class-aware Multiprotocol Label Switching (MPLS)
+ Traffic Engineering
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+ This document specifies a Resource ReSerVation Protocol-Traffic
+ Engineering (RSVP-TE) signaling extension for support of Asynchronous
+ Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching
+ (MPLS) Traffic Engineering.
+
+Table of Contents
+
+ 1. Overview......................................................2
+ 2. Extended RSVP-TE Path Message Format..........................2
+ 2.1 PATH Message Format.......................................3
+ 3. ATM_SERVICECLASS Object.......................................3
+ 4. Handling the ATM_SERVICECLASS Object..........................4
+ 5. Non-support of the ATM_SERVICECLASS Object....................4
+ 6. Security Considerations.......................................4
+ 7. IANA Considerations...........................................5
+ 8. References....................................................5
+ 9. Authors' Addresses............................................5
+ 10. Full Copyright Statement......................................6
+
+
+
+
+
+
+
+
+
+
+
+Malis & Hsiao Informational [Page 1]
+
+RFC 3496 ATM Service Class-aware MPLS Traffic Engineering March 2003
+
+
+1. Overview
+
+ This document defines a Resource ReSerVation Protocol-Traffic
+ Engineering (RSVP-TE) protocol addition to support ATM (Asynchronous
+ Transfer Mode) Service Class-aware MPLS (MultiProtocol Label
+ Switching) Traffic Engineering.
+
+ This protocol addition is used with all MPLS Label Switched Routers
+ (LSRs) and link types (including, but not restricted to, Packet over
+ SONET, Ethernet, and ATM links) to signal traffic engineered paths
+ that can support the ATM service classes as defined by the ATM Forum
+ [TM]. This document does not specify HOW to actually implement the
+ functionality in the MPLS LSRs to emulate the ATM Forum service
+ classes (such as necessary queuing and scheduling mechanisms), only
+ how to signal that the TE path must support the ATM Forum service
+ classes. A useful application for such paths is the carriage of ATM
+ cells encapsulated in IP or MPLS packets in order to use MPLS
+ networks as functional replacements for ATM networks.
+
+2. Extended RSVP-TE Path Message Format
+
+ One new RSVP-TE Object is defined in this document: the
+ ATM_SERVICECLASS Object. Detailed description of this Object is
+ provided below. This new Object is applicable to PATH messages.
+ This specification only defines the use of the ATM_SERVICECLASS
+ Object in PATH messages used to establish LSP (Label Switched Path)
+ Tunnels in accordance with [RSVP-TE]. Such PATH messages contain a
+ Session Object with a C-Type equal to LSP_TUNNEL_IPv4 and a
+ LABEL_REQUEST object.
+
+ Restrictions defined in [RSVP-TE] for support of establishment of LSP
+ Tunnels via RSVP-TE are also applicable to the establishment of LSP
+ Tunnels supporting ATM Service Class-aware traffic engineering. For
+ instance, only unicast LSPs are supported and Multicast LSPs are for
+ further study.
+
+ This new ATM_SERVICECLASS object is optional with respect to RSVP-TE
+ so that general RSVP-TE implementations not concerned with ATM
+ Service Class-aware traffic engineering MPLS LSP setup do not have to
+ support this object.
+
+
+
+
+
+
+
+
+
+
+
+Malis & Hsiao Informational [Page 2]
+
+RFC 3496 ATM Service Class-aware MPLS Traffic Engineering March 2003
+
+
+2.1 PATH Message Format
+
+ The format of the extended PATH message is as follows:
+
+ <PATH Message> ::= <Common Header> [ <INTEGRITY> ]
+ <SESSION> <RSVP_HOP>
+ <TIME_VALUES>
+ [ <EXPLICIT_ROUTE> ]
+ <LABEL_REQUEST>
+ [ <SESSION_ATTRIBUTE> ]
+ [ <DIFFSERV> ]
+ [ <ATM_SERVICECLASS> ]
+ [ <POLICY_DATA> ... ]
+ [ <sender descriptor> ]
+
+ <sender descriptor> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
+ [ <ADSPEC> ]
+ [ <RECORD_ROUTE> ]
+
+3. ATM_SERVICECLASS Object
+
+ The ATM_SERVICECLASS object format is as follows:
+
+ Class Number = 227, C_Type = 1
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved | SC |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Reserved : 29 bits
+ This field is reserved. It must be set to zero on transmission
+ and must be ignored on receipt.
+
+
+ SC : 3 bits
+ Indicates the ATM Service Class. Values currently allowed are:
+ 0: UBR (Unspecified Bit Rate)
+ 1: VBR-NRT (Variable Bit Rate, Non-Real Time)
+ 2: VBR-RT (Variable Bit Rate, Real Time)
+ 3: CBR (Constant Bit Rate)
+ 4-7: reserved
+
+
+
+
+
+
+
+Malis & Hsiao Informational [Page 3]
+
+RFC 3496 ATM Service Class-aware MPLS Traffic Engineering March 2003
+
+
+4. Handling the ATM_SERVICECLASS Object
+
+ To establish an LSP tunnel with RSVP-TE, the sender LSR creates a
+ PATH message with a session type of LSP_Tunnel_IPv4 and with a
+ LABEL_REQUEST object as per [RSVP-TE]. The sender LSR may also
+ include the DIFFSERV object as per [DIFF-MPLS].
+
+ If the LSP is associated with an ATM Service Class, the sender LSR
+ must include the ATM_SERVICECLASS object in the PATH message with the
+ Service-Class (SC) field set to signify the desired ATM Service
+ Class.
+
+ If a path message contains multiple ATM_SERVICECLASS objects, only
+ the first one is meaningful; subsequent ATM_SERVICECLASS object(s)
+ must be ignored and must not be forwarded.
+
+ Each LSR along the path that is ATM_SERVICECLASS-aware records the
+ ATM_SERVICECLASS object, when present, in its path state block.
+
+ The destination LSR responds to the PATH message by sending a RESV
+ message without an ATM_SERVICECLASS object (whether the PATH message
+ contained an ATM_SERVICECLASS object or not).
+
+5. Non-support of the ATM_SERVICECLASS Object
+
+ An LSR that does not recognize the ATM_SERVICECLASS object Class
+ Number must behave in accordance with the procedures specified in
+ [RSVP] for an unknown Class Number with the binary format 11bbbbbb,
+ where b=0 or 1 (i.e., RSVP will ignore the object but forward it
+ unexamined and unmodified).
+
+ An LSR that recognizes the ATM_SERVICECLASS object Class Number but
+ does not recognize the ATM_SERVICECLASS object C-Type, must behave in
+ accordance with the procedures specified in [RSVP] for an unknown
+ C-type (i.e., it must send a PathErr with the error code 'Unknown
+ object C-Type' toward the sender).
+
+ In both situations, this causes the path setup to fail. The sender
+ should notify management that a LSP cannot be established and
+ possibly might take action to retry reservation establishment without
+ the ATM_SERVICECLASS object.
+
+6. Security Considerations
+
+ The solution is not expected to add specific security requirements
+ beyond those of Diff-Serv and existing TE. The security mechanisms
+ currently used with Diff-Serv and existing TE can be used with this
+ solution.
+
+
+
+Malis & Hsiao Informational [Page 4]
+
+RFC 3496 ATM Service Class-aware MPLS Traffic Engineering March 2003
+
+
+7. IANA Considerations
+
+ The IANA has registered a new RSVP Class Number for ATM_SERVICECLASS
+ (227). (See http://www.iana.org/assignments/rsvp-parameters).
+
+8. References
+
+ [DIFF-MPLS] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
+ P., Krishnan, R., Cheval, P. and J. Heinanen, "Multi-
+ Protocol Label Switching (MPLS) Support of Differentiated
+ Services", RFC 3270, May 2002.
+
+ [RSVP] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S.
+ Jazmin , "Resource ReSerVation Protocol (RSVP) -- Version
+ 1 Functional Specification", RFC 2205, September 1997.
+
+ [RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.
+ and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+ Tunnels", RFC 3209, December 2001.
+
+ [TM] ATM Forum Traffic Management Specification Version 4.0,
+ af-tm-0056.000, April 1996.
+
+9. Authors' Addresses
+
+ Andrew G. Malis
+ Vivace Networks, Inc.
+ 2730 Orchard Parkway
+ San Jose, CA 95134
+
+ EMail: Andy.Malis@vivacenetworks.com
+
+
+ Tony Hsiao
+ Vivace Networks, Inc.
+ 2730 Orchard Parkway
+ San Jose, CA 95134
+
+ EMail: Tony.Hsiao@VivaceNetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+Malis & Hsiao Informational [Page 5]
+
+RFC 3496 ATM Service Class-aware MPLS Traffic Engineering March 2003
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malis & Hsiao Informational [Page 6]
+