< draft-malis-diff-te-serviceclass-03.txt		draft-malis-diff-te-serviceclass-04.txt >
			A new Request for Comments is now available in online RFC libraries.
	Internet Draft Andrew G. Malis		RFC 3496
	Document: draft-malis-diff-te-serviceclass-03.txt Tony Hsiao
	Expires: March 2003 Vivace Networks
	September 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 (Resource ReSerVation Protocol-
	Traffic Engineering) 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
	Transfer Mode) Service Class-aware MPLS (MultiProtocol Label
	Switching) 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 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.
	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 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 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 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.
	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, 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 be set 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 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 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 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.
	ATM Service Class-Aware MPLS Traffic Engineering September 2002
	7. 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.
	8. IANA Considerations
	The document calls for IANA to register a new RSVP Class Number in		Title: Protocol Extension for Support of Asynchronous
	the range 224-255, which are assigned by IANA using FCFS		Transfer Mode (ATM) Service Class-aware
	allocation, as discussed in http://www.iana.org/assignments/rsvp-		Multiprotocol Label Switching (MPLS)
	parameters .		Traffic Engineering
			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
	9. References		I-D Tag: draft-malis-diff-te-serviceclass-04.txt
	[Bradner] Bradner, S., "Key words for use in RFCs to Indicate		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3496.txt
	Requirement Levels", BCP 14, RFC 2119, March 1997
	[DIFF-MPLS] Le Faucheur et al, "Multi-Protocol Label Switching		This document specifies a Resource ReSerVation Protocol-Traffic
	(MPLS) Support of Differentiated Services", RFC 3270, May 2002		Engineering (RSVP-TE) signaling extension for support of Asynchronous
			Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching
			(MPLS) Traffic Engineering.
	[RSVP] Braden, R. et al, "Resource ReSerVation Protocol (RSVP) --		This memo provides information for the Internet community. It does
	Version 1 Functional Specification", RFC 2205, September 1997		not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	[RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP		This announcement is sent to the IETF list and the RFC-DIST list.
	Tunnels", RFC 3209, December 2001		Requests to be added to or deleted from the IETF distribution list
			should be sent to IETF-REQUEST@IETF.ORG. Requests to be
			added to or deleted from the RFC-DIST distribution list should
			be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	[TM] ATM Forum Traffic Management Specification Version 4.0, af-tm-		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
	0056.000, April 1996		an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	10. Author's Addresses		To: rfc-info@RFC-EDITOR.ORG
			Subject: getting rfcs
	Andrew G. Malis		help: ways_to_get_rfcs
	Vivace Networks, Inc.
	2730 Orchard Parkway
	San Jose, CA 95134
	Email: Andy.Malis@vivacenetworks.com
	Tony Hsiao		Requests for special distribution should be addressed to either the
	Vivace Networks, Inc.		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
	2730 Orchard Parkway		specifically noted otherwise on the RFC itself, all RFCs are for
	San Jose, CA 95134		unlimited distribution.echo
	Email: Tony.Hsiao@VivaceNetworks.com		Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 12 change blocks.
	233 lines changed or deleted		34 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/