wdiff draft-aboulmagd-ccamp-crldp-ason-ext-01.txt draft-aboulmagd-ccamp-crldp-ason-ext-02.txt

CCAMP O. Aboul-Magd
Internet Draft Nortel Networks
Document: draft-aboulmagd-ccamp-crldp-ason-ext-01.txt October 2002
Category: Informational

CR-LDP ExtensionsA new Request for ASON

Status of this Memo

This document is an Internet-Draft and Comments is now available 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 online RFC libraries.

RFC 3475

Title: Documentation 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 IANA assignments for
Constraint Route Label Distribution Protocol
(CR-LDP) Extensions 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)
Author(s): O. Aboul-Magd
Status: Informational
Date: March 2003
Mailbox: osama@nortelnetworks.com
Pages: 13
Characters: 29995
Updates/Obsoletes/SeeAlso: None

I-D Tag: draft-aboulmagd-ccamp-crldp-ason-ext-02.txt

URL: ftp://ftp.rfc-editor.org/in-notes/rfc3475.txt

Automatic Switched Optical Network (ASON) is an network architecture architecture,
specified by ITU-T Study Group 15, for the introduction of a
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 specifies
a set of reference points that defines the relationship between the
different architectural components.
ASON signaling that runs across
those architectural entities. Signaling over interfaces are described defined in G.7713 [2].

CR-LDP is one
those reference points can make use 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 defined
by the IETF 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 context of Generalized Multi-Protocol Label
Switching (GMPLS) work. This document describes
ASON specific CR-LDP Constraint-Based
LSP setup using LDP (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 signaling over the one
interfaces defined 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. reference points. The
reception purpose 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 document 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 IANA assigns code points
necessary 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 extensions. The protocol specifications
for ASON

This section describes the formats and the procedures use of the two
messages that are required for ASON call and connection control
separation. Those messages CR-LDP extensions 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 found 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 ITU-T documents.

This memo provides 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 Internet community. It does
not specify an Internet standard 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 any kind. Distribution of this
memo 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 unlimited.

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 announcement 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 IETF list and the call RFC-DIST list.
Requests 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 added 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 or deleted from 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 IETF distribution list
should 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 sent 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 IETF-REQUEST@IETF.ORG. Requests 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
added 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 deleted from the source
network. Its length can RFC-DIST distribution list should
be 4, 6, 16, sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP 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 EMAIL may 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 obtained by a
Unique Access Point Code.

4.1.1 Call ID Procedure

The following processing rules are applicable sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the CALL ID TLV:

- For initial calls, the calling/originating party call controller
must set the CALL ID values to all-zeros
- message body
help: ways_to_get_rfcs. For a new call request, the source networks call controller (SNCC)
sets the appropriate type and value example:

To: rfc-info@RFC-EDITOR.ORG
Subject: getting rfcs

help: ways_to_get_rfcs

Requests 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 special distribution should 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 addressed to unavailable resources, the node will inform
the initiator of the Label Request message of either the location
author 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 RFC 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 question, or to Free LC

6. IANA Consideration

This draft uses RFC-Manager@RFC-EDITOR.ORG. Unless
specifically noted otherwise on 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 itself, all RFCs are for the new error codes as listed in section 5 of
this draft.

9. References

1 M. Mayer, "Architecture
unlimited distribution.echo
Submissions 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
2001.

Draft-aboulmagd-crldp-ason-ext-01.txt October 2002

4 B. Jamoussi, Ed., "Constraint-Based LSP Setup Using LDP", RFC
3212, January 2002.

5 P. Ashwood-Smith, et. al., "Generalized MPLS Signaling-CR-LDP
Extensions", draft-ietf-mpls-generalized-cr-ldp-07.txt, August
2002

6 B. Rajagopalan, "User Network Interface (UNI) 1.0 Signaling
Specification", OIF-UNI-01.1, October 2001.

7 B. Rajagopalan, "LDP and RSVP Extensions Requests for Optical UNI
Signaling" draft-bala-uni-ldp-rsvp-extensions-02.txt, work in
progress, 2002.

11. Author's Addresses

Osama Aboul-Magd
Nortel Networks
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

"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may Comments should be copied and furnished sent to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation 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
RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures RFC
Authors, for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into further information.