ATM class-aware MPLS TE: Protocol Extension for Support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering
An RSVP-TE extension for signaling ATM service class requirements in label-switched paths.
Malis, A. G. and T. Hsiao, "Protocol Extension for Support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering", RFC 3496, DOI 10.17487/RFC3496, March 2003, <https://www.rfc-editor.org/info/rfc3496>.
@misc{rfc3496,
series = {Request for Comments},
number = 3496,
howpublished = {RFC 3496},
publisher = {RFC Editor},
doi = {10.17487/RFC3496},
url = {https://www.rfc-editor.org/info/rfc3496},
author = {A. G. Malis and T. Hsiao},
title = {{Protocol Extension for Support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering}},
pagetotal = 6,
year = 2003,
month = mar,
} RFC text
Contents
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
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.
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
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.
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
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.
AI ELI5
On this page
§1Overview
RFC 3496 defines a signaling extension for RSVP-TE (Resource ReSerVation Protocol - Traffic Engineering) to support ATM service classes in MPLS networks. The extension allows label-switched routers (LSRs) to signal which ATM service class a path must support when establishing label-switched path (LSP) tunnels.
The mechanism is agnostic to link types: it works with Ethernet, SONET, ATM links, and others. The RFC does not specify how to implement ATM service class behavior (such as queuing and scheduling); it only defines how to request that a path support a particular class. A key use case is carrying ATM cells encapsulated in MPLS packets to use MPLS networks as replacements for ATM networks.
Routers need to tell each other what kind of service quality they need for a path, just like a shipping company picks express or standard delivery. This document shows how to include that request in MPLS setup messages.
§2The ATM_SERVICECLASS Object
The ATM_SERVICECLASS object is a new RSVP-TE object included in PATH messages used to establish LSP tunnels. It is optional, so RSVP-TE implementations that do not need ATM service class support do not have to recognize it.
The object has a Class Number of 227 and contains a 3-bit Service Class (SC) field that specifies the desired ATM class: 0 for UBR (Unspecified Bit Rate), 1 for VBR-NRT (Variable Bit Rate, Non-Real Time), 2 for VBR-RT (Variable Bit Rate, Real Time), and 3 for CBR (Constant Bit Rate). The remaining 29 bits are reserved and must be set to zero. If multiple ATM_SERVICECLASS objects appear in a message, only the first is meaningful; subsequent ones are ignored.
The object is a small tag in the setup message that says which class the path needs. It has four possible values for different service quality levels, plus some spare bits for future use.
§3Handling and Non-support
When a sender LSR wants to establish an LSP with ATM service class support, it includes the ATM_SERVICECLASS object in the PATH message with the SC field set to the desired class. Each LSR along the path that recognizes this object records it in the path state block.
The destination LSR responds with a RESV message but does not include an ATM_SERVICECLASS object, regardless of whether the PATH message contained one. LSRs that do not recognize the ATM_SERVICECLASS class number or C-Type follow standard RSVP error procedures: they may ignore the object and forward it unchanged (if the class number format allows), or they may send a PathErr message with an 'Unknown object C-Type' error toward the sender, causing the path setup to fail.
The sender puts the class request in the setup message. Routers that understand it remember it. If a router does not understand it, the setup may fail, and the sender should try again without the request or check what went wrong.
§4Security
RFC 3496 states that the ATM_SERVICECLASS extension does not add specific security requirements beyond those of Differentiated Services (Diff-Serv) and existing MPLS traffic engineering. The security mechanisms already used with Diff-Serv and MPLS TE are sufficient to protect this extension.
This addition does not introduce new security risks because the security methods already used for MPLS path setup work fine here too.
§5IANA Assignments
The IANA has assigned RSVP Class Number 227 to the ATM_SERVICECLASS object. This class number identifies the object type in RSVP-TE messages and ensures there is no conflict with other RSVP object types.
The Internet authority registered an official identification number for this new object type so that all implementations can recognize it the same way.