Internet Draft Andrew G. Malis
Document: draft-malis-diff-te-serviceclass-03.txt Tony Hsiao
Expires: March 2003 Vivace Networks
September 2002A new Request for Comments is now available in online RFC libraries.
RFC 3496
Title: Protocol Extension for Support of ATM Asynchronous
Transfer Mode (ATM) Service Class-aware MPLS
Multiprotocol Label Switching (MPLS)
Traffic Engineering
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Author(s): A. G. Malis, T. Hsiao
Status: Informational
Date: March 2003
Mailbox: Andy.Malis@vivacenetworks.com,
Tony.Hsiao@VivaceNetworks.com
Pages: 6
Characters: 11431
Updates/Obsoletes/SeeAlso: None
I-D Tag: draft-malis-diff-te-serviceclass-04.txt
URL: ftp://ftp.rfc-editor.org/in-notes/rfc3496.txt
This document specifies an RSVP-TE (Resource a Resource ReSerVation Protocol-
Traffic Engineering) Protocol-Traffic
Engineering (RSVP-TE) signaling extension for support of ATM
(Asynchronous Transfer Mode) Service Class-aware MPLS
(Multiprotocol Label Switching) Traffic Engineering.
Table of Contents
1. Overview......................................................2
2. Terminology...................................................2
3. ATM Service Class-Aware Traffic Engineering-related RSVP Message
Format...........................................................2
3.1 PATH Message Format.......................................3
4. ATM_SERVICECLASS Object.......................................3
5. Handling the ATM_SERVICECLASS Object..........................4
6. Non-support of the ATM_SERVICECLASS Object...................45
7. Security Considerations.......................................5
8. IANA Considerations...........................................5
9. References....................................................5
ATM Service Class-Aware MPLS Traffic Engineering September 2002
10. Author's Addresses..........................................56
1. Overview
This document defines an RSVP-TE (Resource ReSerVation Protocol-
Traffic Engineering) protocol addition to support ATM (Asynchronous Asynchronous
Transfer Mode) Mode (ATM) Service Class-aware MPLS (MultiProtocol Multiprotocol Label
Switching) Switching
(MPLS) Traffic Engineering.
This protocol addition is used with all MPLS LSRs (Label Switched
Routers) 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 memo provides information for the
ATM Forum [TM]. This document Internet community. It 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 an Internet standard of ATM cells encapsulated in IP or MPLS packets in
order to use MPLS networks as functional replacements for ATM
networks.
An LSR supporting ATM Service Class-aware traffic engineering in
compliance with this specification MUST support the
ATM_SERVICECLASS Object as defined in Section 3. It MUST support
Class-Type value 1, and MAY support other Class-Type values.
2. Terminology
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
[Bradner].
3. ATM Service Class-Aware Traffic Engineering-related RSVP Message
Format
One new RSVP Object is defined in this document: the
ATM_SERVICECLASS Object. Detailed description any kind. Distribution of this Object
memo is
provided below. unlimited.
This new Object announcement is applicable sent 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 IETF list and a
LABEL_REQUEST object.
Restrictions defined in [RSVP-TE] for support of establishment of
LSP Tunnels via RSVP are also applicable to the establishment of
LSP Tunnels supporting ATM Service Class-aware traffic engineering.
ATM Service Class-Aware MPLS Traffic Engineering September 2002
For instance, only unicast LSPs are supported and Multicast LSPs
are for further study.
This new ATM_SERVICECLASS object is optional with respect RFC-DIST list.
Requests to RSVP
so that general RSVP implementations not concerned with ATM Service
Class-aware traffic engineering MPLS LSP setup do not have be added to
support this object.
3.1 PATH Message Format
The format of the 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> ]
4. ATM_SERVICECLASS Object
The ATM_SERVICECLASS object format is as follows:
Class Number = TBD, C_Type = 1
(This will use an official Class Number in the range 224-255, which
are assigned by IANA using FCFS allocation. At the time of this
writing, or deleted from the next available number in this range is 227.)
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 IETF distribution list
should be set sent to IETF-REQUEST@IETF.ORG. Requests to zero on transmission
and must be ignored on receipt.
ATM Service Class-Aware MPLS Traffic Engineering September 2002
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
5. Handling the ATM_SERVICECLASS Object
To establish an LSP tunnel with RSVP, 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
added to signify the desired ATM Service
Class.
If a path message contains multiple ATM_SERVICECLASS objects, only or deleted from the first one is meaningful; subsequent ATM_SERVICECLASS object(s)
must be ignored and must not RFC-DIST distribution list should
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 sent to the PATH message RFC-DIST-REQUEST@RFC-EDITOR.ORG.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending a RESV
message without a ATM_SERVICECLASS object (whether the PATH message
contained a ATM_SERVICECLASS object or not).
6. 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 EMAIL message to rfc-info@RFC-EDITOR.ORG with the procedures specified in [RSVP] message body
help: ways_to_get_rfcs. For example:
To: rfc-info@RFC-EDITOR.ORG
Subject: getting rfcs
help: ways_to_get_rfcs
Requests 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 special distribution should notify management that a LSP cannot be established and
possibly might take action addressed to retry reservation establishment
without either the ATM_SERVICECLASS object.
ATM Service Class-Aware MPLS Traffic Engineering September 2002
7. Security Considerations
The solution is not expected to add specific security requirements
beyond those
author of Diff-Serv and existing TE. The security mechanisms
currently used with Diff-Serv and existing TE can be used with this
solution.
8. IANA Considerations
The document calls for IANA to register a new RSVP Class Number the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
specifically noted otherwise on the range 224-255, which RFC itself, all RFCs are assigned by IANA using FCFS
allocation, as discussed in http://www.iana.org/assignments/rsvp-
parameters .
9. References
[Bradner] Bradner, S., "Key words for use in RFCs
unlimited distribution.echo
Submissions for Requests for Comments should be sent to Indicate
Requirement Levels", BCP 14,
RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2119, March 1997
[DIFF-MPLS] Le Faucheur et al, "Multi-Protocol Label Switching
(MPLS) Support of Differentiated Services", RFC 3270, May 2002
[RSVP] Braden, R. et al, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205, September 1997
[RSVP-TE] Awduche et al, "RSVP-TE: Extensions 2223, Instructions to RSVP for LSP
Tunnels", RFC 3209, December 2001
[TM] ATM Forum Traffic Management Specification Version 4.0, af-tm-
0056.000, April 1996
10. Author's 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
Authors, for further information.