Internet Draft Andrew G. Malis
Document: draft-malis-diff-te-serviceclass-00.txt Tony Hsiao
Expires: October 2002 Vivace Networks
April 2002
Protocol Extension for Support of ATM
Service Class-aware 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
This document specifies an RSVP-TE signaling extension for support
of ATM Service Class-aware MPLS Traffic Engineering.
Table of Contents
1. Overview......................................................2
2. ATM Service Class-Aware Traffic Engineering-related RSVP Message
Format...........................................................2
2.1 PATH Message Format.......................................2
3. SERVICECLASS Object...........................................3
4. Handling the SERVICECLASS Object..............................3
5. Non-support of the SERVICECLASS Object........................4
6. Security Considerations.......................................4
References.......................................................4
Author's Addresses...............................................4
Malis, Townsley Expires - October 2002 [Page 1]
Generalized Fragmentation for PWE3 Protocols April 2002
1. Overview
draft-ietf-tewg-diff-te-proto-00.txt [DS-MPLS-TE] defines protocol
additions for support of Diff-Serv-aware MPLS Traffic Engineering.
Similarly, this document defines an RSVP-TE protocol addition to
support ATM Service Class-aware MPLS Traffic Engineering.
2. ATM Service Class-Aware Traffic Engineering-related RSVP Message
Format
One new RSVP Object is defined in this document: the 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 SERVICECLASS Object in PATH messages used to
establish LSP Tunnels in accordance with [RSVP-TE] and thus
containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4
and containing 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.
For instance, only unicast LSPs are supported and Multicast LSPs
are for further study.
This new SERVICECLASS object is optional with respect to RSVP so
that general RSVP implementations not concerned with ATM Service
Class-aware traffic engineering MPLS LSP setup do not have to
support this object.
An LSR supporting ATM Service Class-aware traffic engineering in
compliance with this specification MUST support the SERVICECLASS
Object. It MUST support Class-Type value 1, and MAY support other
Class-Type values.
2.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> ]
[ <SERVICECLASS> ]
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
Malis Expires - October 2002 [Page 2]
Generalized Fragmentation for PWE3 Protocols April 2002
<sender descriptor> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
3. SERVICECLASS Object
The 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.)
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 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 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 SERVICECLASS objects, only the
first one is meaningful; subsequent SERVICECLASS object(s) must be
ignored and must not be forwarded.
Each LSR along the path that is SERVICECLASS-aware records the
SERVICECLASS object, when present, in its path state block.
Malis Expires - October 2002 [Page 3]
Generalized Fragmentation for PWE3 Protocols April 2002
The destination LSR responds to the PATH message by sending a RESV
message without a SERVICECLASS object (whether the PATH message
contained a SERVICECLASS object or not).
5. Non-support of the SERVICECLASS Object
An LSR that does not recognize the 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 SERVICECLASS object Class Number but
does not recognize the 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 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.
References
[DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", draft-
ietf-mpls-diff-ext-09.txt, April 2001
[DS-MPLS-TE] Le Faucheur et al, "Protocol extensions for support of
Diff-Serv-aware MPLS Traffic Engineering", draft-ietf-tewg-diff-te-
proto-00.txt, work in progress
[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 to RSVP for LSP
Tunnels", RFC 3209, December 2001
Author's Addresses
Andrew G. Malis
Malis Expires - October 2002 [Page 4]
Generalized Fragmentation for PWE3 Protocols April 2002
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 Expires - October 2002 [Page 5]