< draft-aboulmagd-ccamp-crldp-ason-ext-01.txt		draft-aboulmagd-ccamp-crldp-ason-ext-02.txt >
			A new Request for Comments is now available in online RFC libraries.
	CCAMP O. Aboul-Magd		RFC 3475
	Internet Draft Nortel Networks
	Document: draft-aboulmagd-ccamp-crldp-ason-ext-01.txt October 2002
	Category: Informational
	CR-LDP Extensions for ASON
	Status of this Memo
	This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026 except that the right to
	produce derivative works is not granted.
	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.
	1. Abstract
	Automatic Switched Optical Network (ASON) is an network architecture
	for the introduction of control plane for optical networks. The
	development and the standardization of ASON have been going on at
	the ITU-T and its recommendation G.8080 [1]. The control plane
	architecture introduces a set of reference points between the
	different architectural components. ASON signaling that runs across
	those interfaces are described in G.7713 [2].
	CR-LDP is one of the protocols under consideration at the ITU for
	the realization of G.7713 and its dynamic connection management. The
	work specific to CR-LDP extensions for ASON is documented in
	G.7713.3 (scheduled for consent in January 2003).
	This draft introduces those CR-LDP extensions that are specific to
	ASON. This draft should be considered in junction with RFC 3036 [3],
	RFC 3212 [4], and RFC (CR-LDP extensions for GMPLS) [5].
	2. Overview of CR-LDP Extensions for ASON
	Draft-aboulmagd-crldp-ason-ext-01.txt October 2002
	In addition to the CR-LDP GMPLS extensions [5], this draft describes
	ASON specific CR-LDP extensions covering the following ASON
	signaling requirements:
	- Call and connection control separation
	- Support of soft permanent connections (SPC)
	- Crankback
	- Additional error codes
	An important ASON architectural principle is the separation between
	the call and the connection controller as described in G.8080. Call
	and connection control separation allows for a call with multiple
	connections associated to it. It also allows for a call with no
	connections (a temporary situation that might be useful during
	recovery).
	There are two models to achieve this separation. The first model is
	a one where the call set up request is always accompanied by a
	connection request. The second model is the one in which call set up
	is done independent from connection set up. The first model is
	usually referred to as logical separation, while the second model is
	usually referred to as complete separation. CR-LDP extensions for
	ASON support the two separation models.
	Two new messages are introduced for call operations (set up and
	release). The Call Setup message is used for those cases where
	complete separation is required. Otherwise the LDP Label Request
	message is used for logical separation.
	Connection set up request must indicate the call to which the
	connection needs to be associated to. A Call ID TLV is introduced to
	achieve this goal. The structure of the Call ID allows it to have a
	global or an operator scope.
	Call release is always achieved using Call Release message. The
	reception of the call Release messages signifies the intention to
	remove all connections that are associated to the call. Connection
	release is achieved using the same CR-LDP label release procedure
	(using LDP Label Release and Label Withdraw messages).
	A Call Capability TLV is also introduced to explicitly indicate the
	capability of the requested call.
	An SPC service assumes that both source and destination user-to-
	network connection segments are provisioned while the network
	connection segment is set up via control plane. For example when the
	initial request is received from an external source, e.g. from a
	management system, there is an implicit assumption that the control
	plane has adequate information to determine the specific destination
	(network-to-user) link connection to use. Support for CR-LDP is
	provided by the use of the Egress Label TLV as defined in OIF UNI
	1.0 [6] and [7].
	Draft-aboulmagd-crldp-ason-ext-01.txt October 2002
	3. CR-LDP Messages for ASON
	This section describes the formats and the procedures of the two
	messages that are required for ASON call and connection control
	separation. Those messages are the Call Setup messages and the Call
	Release message.
	3.1 Call Setup Message
	The format of the Call Setup message is:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0| Call Setup (TBD) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source ID TLV |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Dest ID TLV |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Call ID TLV |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Call Capability TLV |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Optional Parameters |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Message ID:
	Is as defined in RFC3036 [3].
	Source ID TLV:
	Is as defined in UNI 1.0 [6] and in [7]
	Dest ID TLV:
	Is as defined in UNI 1.0 [6] and in [7]
	Call ID TLV:
	Is as defined in section 4.1 of this draft
	Call Capability TLV:
	Is as defined in section 4.2 of this draft
	3.1.2 Call Setup Procedure
	The Calling party sends the Call Setup message whenever a new call
	needs to be set up with no connection associated to it. The Call
	Setup message SHALL contain all the information required by the
	Draft-aboulmagd-crldp-ason-ext-01.txt October 2002
	network to process the call. In Particular the Call Setup message
	shall include the calling and called party addresses as specified by
	the Source ID and Dest ID TLV. The setup message MUST include Call
	ID TLV. The call control entity shall identify the call using the
	selected identifier for the lifetime of the call. The Call Setup
	message shall progress through the network to the called party. The
	called party may accept or reject the incoming call. An LDP
	Notification message with the appropriate status code shall be used
	to inform the calling party whether the setup is successful. The
	call can be rejected by either the network, e.g. for policy reasons,
	or by the called party.
	3.2 The Call Release Message
	This format of the Call Release message is:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0| Call Release (TBD) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source ID TLV |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Dest ID TLV |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Call ID TLV |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Optional Parameters |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	3.2.1 Call Release Procedure:
	The Call Release message is sent by any entity of the network to
	indicate the desire to terminate an already established call. The
	Call Release message MUST include the Call ID TLV of the call to be
	terminated. Confirmation of call release is indicated to the request
	initiator using a Notification message with the appropriate status
	code. Reception and processing of the Call Release message MUST
	trigger the release of all connections that are associated to that
	call. Connection release follows the normal CR-LDP procedure using
	Label Release and Label Withdraw messages.
	4. CR-LDP TLV for ASON
	This section describes the Call ID TLV and the Call Capability TLV
	introduced for ASON.
	4.1 Call ID TLV
	Draft-aboulmagd-crldp-ason-ext-01.txt October 2002
	An established call may be identified by a Call ID. The Call ID is a
	globally unique identifier that is set by the source network. The
	structure for the Call ID (to guarantee global uniqueness) is to
	concatenate a globally unique fixed identifier (composed of country
	code, carrier code, unique access point code) with an operator
	specific identifier (where the operator specific identifier is
	composed of a source transport network element address and a local
	Identifier).
	Therefore, a generic CALL_ID with global uniqueness includes <global
	Id> (composed of <country code> plus <carrier code> plus <unique
	access point code>) and <operator specific Id> (composed of <source
	transport network element address> plus <local Identifier>). For a
	CALL_ID that only requires operator specific uniqueness only the
	<operator specific Id> is needed, while for a CALL_ID that requires
	to be globally unique both <global ID> and <operator specific Id>
	are needed.
	The <global Id> shall consist of a three-character International
	Segment (the <country code>) and a twelve-character National Segment
	(the <carrier code> plus <unique access point code>). These
	characters shall be coded according to ITU-T Recommendation T.50.
	The International Segment (IS) field provides a 3 character ISO 3166
	Geographic/Political Country Code. The country code shall be based
	on the three-character uppercase alphabetic ISO 3166 Country Code
	(e.g., USA, FRA).
	The National Segment (NS) field consists of two sub-fields: the ITU
	Carrier Code followed by a Unique Access Point Code. The ITU Carrier
	Code is a code assigned to a network operator/service provider,
	maintained by the ITU-T Telecommunication Service Bureau in
	association with Recommendation M.1400. This code shall consist of
	1-6 left-justified characters, alphabetic, or leading alphabetic
	with trailing numeric. The unique access point code shall be a
	matter for the organization to which the country code and ITU
	carrier code have been assigned, provided that uniqueness is
	guaranteed. This code shall consist of 6-11 characters, with
	trailing NULL, completing the 12-character National Segment.
	The format of the operator specific (Op-Sp) CALL_ID TLV:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|U|F|Op-Sp Call ID (TBD) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source Transport Element Address (STEA Sub TLV) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local Identifier |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Draft-aboulmagd-crldp-ason-ext-01.txt October 2002
	STEA Sub TLV:
	The Source Transport Element Address is an address of the
	transport network element (SSN) controlled by the source
	network. Its length can be 4, 6, 16, or 20 byte long. The STEA
	Sub TLV is TLV Type 1.
	Local Identifier:
	A 64-bit identifier that remains constant over the life of the
	call.
	The format of the globally unique (GU) Call ID TLV:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|U|F|GU Call ID (TBD) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | IS |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| NS |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source Transport Element Address (STEA sub TLV) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local Identifier |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	International Segment (IS):
	To be coded according to ITU-T recommendation T.50. It provides
	a 3 character uppercase country code, e.g. USA, FRA, etc.
	National Segment (NS):
	NS consists of two fields, the ITU carrier Code followed by a
	Unique Access Point Code.
	4.1.1 Call ID Procedure
	The following processing rules are applicable to the CALL ID TLV:
	- For initial calls, the calling/originating party call controller
	must set the CALL ID values to all-zeros
	- For a new call request, the source networks call controller (SNCC)
	sets the appropriate type and value for the CALL ID.
	- For an existing call (in case Call ID is non zero) the SNCC
	verifies existence of the call
	- The Call ID TLV on all messages MUST be sent from ingress call
	controller to egress call controller by all other intermediate
	controlling without altering.
	- The destination user/client receiving the request uses the CALL ID
	values as reference to the requested call between the source user
	and itself. Subsequent actions related to the call uses the CALL
	ID as the reference identifier.
	Draft-aboulmagd-crldp-ason-ext-01.txt October 2002
	4.2 Call Capability TLV
	The format of the Call Capability TLV is:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|U|F| Call Capabaility(TBD) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Call Capability |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Call Capability TLV is used to explicitly indicate the
	configuration potentiality of the call.
	4.3 Crankback TLV
	Crankback requires that when the Label Request message is blocked at
	a particular node due to unavailable resources, the node will inform
	the initiator of the Label Request message of the location of the
	blockage. The initiator can then re-compute new explicit routes that
	avoid the area where resource shortage is detected. A new Label
	Request message is sent that includes the new route.
	The support of crankback in CR-LDP is facilitated by the
	introduction of a Crankback TLV. An LDP Notification message is used
	to inform the Label Request message initiator of the blocking
	condition. The Notification message includes the Crankback TLV that
	indicates the location of resource shortage. The location of the
	resource shortage is identified using the ER-HOP TLV. The encoding
	of the Crankbck TLV is:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|U|F| Crankback(TBD) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ER-HOP TLV |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	5. Additional Error Codes
	G.7713 includes a number of error conditions that are currently
	missing from CR-LDP related RFCs. The list of those error conditions
	is given below. There is the need to assign status codes to them.
	Invalid SNP ID
	Calling Party busy
	Unavailable SNP ID
	Invalid SNPP ID
	Draft-aboulmagd-crldp-ason-ext-01.txt October 2002
	Unavailable SNPP ID
	Failed to create SNC
	Failed to establish LC
	Invalid A End-User Name
	Invalid Z End-User Name
	Invalid CoS
	Unavailable CoS
	Invalid GoS
	Unavailable GoS
	Failed Security Check
	TimeOut
	Invalid Call Name
	Failed to Release SNC
	Failed to Free LC
	6. IANA Consideration
	This draft uses the LDP RFC 3036 [3] name spaces; see
	http://www.iana.org/assignments/ldp-namespaces, which require
	assignment for the following messages:
	Call Setup
	Call Release
	The assignment for the following TLVs
	Op-Sp Call ID TLV
	GU Call ID TLV
	Call Capability TLV
	Crankback TLV
	In addition to those TLVs described here, G.7713.3 requires a code
	point for the Link Feedback TLV as described in "draft-ietf-mpls-te-
	feed-05.txt"
	The assignment for the new error codes as listed in section 5 of
	this draft.
	9. References
	1 M. Mayer, "Architecture for Automatic Switched Optical Networks
	(ASON)", ITU G.8080/Y1304, V1.0, October 2001.
	2 Z. Li, "Distributed Call and Connection Management", ITU
	G.7713/Y1704, October 2001.
	3 L. Andersson,et. al., "LDP Specifications", RFC 3036, January		Title: Documentation of IANA assignments for
	2001.		Constraint Route Label Distribution Protocol
			(CR-LDP) Extensions for Automatic Switched Optical
			Network (ASON)
			Author(s): O. Aboul-Magd
			Status: Informational
			Date: March 2003
			Mailbox: osama@nortelnetworks.com
			Pages: 13
			Characters: 29995
			Updates/Obsoletes/SeeAlso: None
	Draft-aboulmagd-crldp-ason-ext-01.txt October 2002		I-D Tag: draft-aboulmagd-ccamp-crldp-ason-ext-02.txt
	4 B. Jamoussi, Ed., "Constraint-Based LSP Setup Using LDP", RFC		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3475.txt
	3212, January 2002.
	5 P. Ashwood-Smith, et. al., "Generalized MPLS Signaling-CR-LDP		Automatic Switched Optical Network (ASON) is an architecture,
	Extensions", draft-ietf-mpls-generalized-cr-ldp-07.txt, August		specified by ITU-T Study Group 15, for the introduction of a
	2002		control plane for optical networks. The ASON architecture specifies
			a set of reference points that defines the relationship between the
			ASON architectural entities. Signaling over interfaces defined in
			those reference points can make use of protocols that are defined
			by the IETF in the context of Generalized Multi-Protocol Label
			Switching (GMPLS) work. This document describes Constraint-Based
			LSP setup using LDP (CR-LDP) extensions for signaling over the
			interfaces defined in the ASON reference points. The purpose of
			the document is to request that the IANA assigns code points
			necessary for the CR-LDP extensions. The protocol specifications
			for the use of the CR-LDP extensions are found in ITU-T documents.
	6 B. Rajagopalan, "User Network Interface (UNI) 1.0 Signaling		This memo provides information for the Internet community. It does
	Specification", OIF-UNI-01.1, October 2001.		not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	7 B. Rajagopalan, "LDP and RSVP Extensions for Optical UNI		This announcement is sent to the IETF list and the RFC-DIST list.
	Signaling" draft-bala-uni-ldp-rsvp-extensions-02.txt, work in		Requests to be added to or deleted from the IETF distribution list
	progress, 2002.		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.
	11. Author's Addresses		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
			an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	Osama Aboul-Magd		To: rfc-info@RFC-EDITOR.ORG
	Nortel Networks		Subject: getting rfcs
	P.O. Box 3511, Station "C"
	Ottawa, Ontario, Canada
	K1Y-4H7
	Phone: 613-599-9104
	Email: osama@nortelnetworks.com
	Draft-aboulmagd-crldp-ason-ext-01.txt October 2002
	Full Copyright Statement		help: ways_to_get_rfcs
	"Copyright (C) The Internet Society (date). All Rights Reserved.		Requests for special distribution should be addressed to either the
	This document and translations of it may be copied and furnished to		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
	others, and derivative works that comment on or otherwise explain it		specifically noted otherwise on the RFC itself, all RFCs are for
	or assist in its implmentation may be prepared, copied, published		unlimited distribution.echo
	and distributed, in whole or in part, without restriction of any		Submissions for Requests for Comments should be sent to
	kind, provided that the above copyright notice and this paragraph		RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
	are included on all such copies and derivative works. However, this		Authors, for further information.
	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
End of changes. 12 change blocks.
	439 lines changed or deleted		42 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/