WDIFF

draft-aboulmagd-ccamp-crldp-ason-ext-00.txt --> draft-aboulmagd-ccamp-crldp-ason-ext-01.txt

CCAMP WG O. Aboul-Magd
Internet Draft Nortel Networks
Document: draft-aboulmagd-ccamp-crldp-ason-ext-00.txt
June 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 [1]. 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

This draft considers CR-LDP extensions

Automatic Switched Optical Network (ASON) is an network architecture
for the support introduction of control plane for optical networks. The
development and the ITU standardization of ASON architecture (G.8080) [2] have been going on at
the ITU-T and its signaling requirements
(G.7713) [3]. recommendation G.8080 [1]. The CCAMP WG charter includes control plane
architecture introduces a set of reference points between the statement:
"Define signalling protocols and measurement protocols such
different architectural components. ASON signaling that
they support multiple physical path and tunnel technologies (e.g. O-
O and O-E-O optical switches, ATM and Frame Relay switches, MPLS,
GRE) using input from technology-specific working groups such as
MPLS, IPO, etc."

This draft runs across
those interfaces are described in G.7713 [2].

CR-LDP is within one of the CCAMP charter since it defines extensions
to a CCAMP-defined signaling protocol, namely CR-LDP, protocols under consideration at the ITU for transport
network tunnels.

2. Introduction

During
the IETF meeting realization of G.7713 and its dynamic connection management. The
work specific to CR-LDP extensions for ASON is documented in Minneapolis March 2002, an ITU liasian
was presented requesting that IETF CCAMP WG
G.7713.3 (scheduled for consent in January 2003).

This draft introduces those CR-LDP extensions that are specific to consider
ASON. This draft should be considered in junction with RFC 3036 [3],
RFC 3212 [4], and RFC (CR-LDP extensions for the GMPLS suite GMPLS) [5].

2. Overview of signaling protocols CR-LDP Extensions for ASON network
architecture [2] and its signaling requirements [3].

O. Aboul-Magd Expires January Informational- Expires: March 2003 1

draft-aboulmagd-crldp-ext-ason-00.txt June
Draft-aboulmagd-crldp-ason-ext-01.txt October 2002

The liaison identifies five areas where extensions are needed

In addition to
meet the CR-LDP GMPLS extensions [5], this draft describes
ASON specific CR-LDP extensions covering the following ASON
signaling requirements. Those areas are:

a. requirements:

- Call and connection control separation

b. Additional Error Codes/Values

c. Restart Mechanism

d. Support for Crankback

e.
- Support for of soft permanent connections (SPC)

This draft is a follow up to the draft presented during the
Minneapolis meeting.

3. CR-LDP Support for Call and Connection Separation

One
- Crankback
- Additional error codes

An important architecture principle of ASON architectural principle is that the separation between
the call and the connection controller as described in G.8080. Call
and connection control are treated separately. With this separation
there could be the case where allows for a single call has one or more with multiple
connections associated to it. It is also quite possible to have allows for a call with no
connections associated to it, for example (a temporary situation that might be useful during
recovery times.

The current set of GMPLS signaling protocols, i.e. CR-LDP and RSVP-
TE do not support
recovery).

There are two models to achieve this requirement. In reality the notion of separation. The first model is
a call
is absent in both protocols. A label switched path (LSP), or a
connection, is set end-to-end by assigning a set of labels on the
different nodes along the path. Once an LSP is deleted, all the
information regarding its end points is lost.

This section describes messages and TLV extensions necessary to
introduce call and connection control separation to CR-LDP. Those
extensions are dependent upon the call/connection model considered.
In general there are two cases that have been one where the subject of some
discussion at ITU. Those cases are:

a. A call setup set up request is always accompanied by a
connection setup. This
case request. The second model is sometimes referred to as "logical separation"

b. A the one in which call setup set up
is done separately independent from connection setup. In this
case call setup set up. The first model is mainly for the exchange of call control
information between
usually referred to as logical separation, while the two end points of a call. This case second model is
sometimes
usually referred to as "complete separation"

In both cases connections associated with complete separation. CR-LDP extensions for
ASON support the two separation models.

Two new messages are introduced for call could be setup or
torn down after the successful set operations (set up of the call. Furthermore the
release of a call should result in clearing of all the connection
associated with it.

3.1 and
release). The Call Setup in CR-LDP

Aboul-Magd Expires: January 2003 2

draft-aboulmagd-crldp-ext-ason-00.txt June 2002

Call setup in CR-LDP makes the distinction between the two message is used for those cases
mentioned above. In the case where the call setup request
complete separation is always
accompanied by a connection setup, required. Otherwise the same LDP Label Request
message used for
connection setup (Label Request) is at the same time used for call
setup.

For logical separation.

Connection set up request must indicate the other cases where a call setup is done independently from to which the
connection setup, a new LDP message (Call Setup) needs to be associated to. A Call ID TLV is introduced. introduced to
achieve this goal. The introduction structure of the Call ID allows it to have a new message
global or an operator scope.

Call release is justified by always achieved using Call Release message. The
reception of the observation
that call Release messages signifies the existing LDP messages perform procedures at intention to
remove all connections that are associated to the connection,
or LSP, level. In this case call. Connection
release is achieved using the setup of a call doesn't include any 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 those procedure. Thus 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 new message
management system, there is justified an implicit assumption that the control
plane has adequate information to avoid determine the
inevitable overloading of specific destination
(network-to-user) link connection to use. Support for CR-LDP is
provided by the semantics use of existing messages.

3.1.1 the Egress Label TLV Encodings as defined in OIF UNI
1.0 [6] and [7].

O. Aboul-Magd Informational- Expires: March 2003 2
Draft-aboulmagd-crldp-ason-ext-01.txt October 2002

3. CR-LDP Messages for Call Operation ASON

This section describes the encoding for new TLV required for call
setup. Two new TLV are introduced. Those are Call ID TLV formats and Call
Capability TLV. Other TLV the procedures of the two
messages that are required for ASON call operation are
the Source ID TLV and the Dest ID TLV (Src ID and Dest ID TLV connection control
separation. Those messages are
defined for the OIF UNI [4] in the context of Transport Network
Assigned (TNA) address).

3.1.1.1 Call ID TLV

The purpose of the call identifier (Call ID) TLV is to locally
identify a call in the context of separated call Setup messages and connection
control environment. the Call
Release message.

3.1 Call Setup Message

The format of the Call ID TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|
|0| Call ID Setup (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Call
| Source ID has a minimum length of 32 bits.

3.1.1.2 Call Capability TLV

The Call Capability (Call Cap) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest ID TLV is used |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 explicitly indicate be set up with no connection associated to it. The Call
Setup message SHALL contain all the configuration of potentiality information required by the

O. Aboul-Magd Informational- Expires: March 2003 3
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, e.g. pt-to-pt 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 Capability TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Aboul-Magd Expires: January 2003 3

draft-aboulmagd-crldp-ext-ason-00.txt June 2002

|U|F|
|0| Call Cap Release (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call Capability Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.1.1.3
| Source ID TLV

The format of the Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest ID TLV is as defined in the OIF UNI 1.0 [4]
and [5]

3.1.1.4 Dest |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.1 Call Release Procedure:

The format Call Release message is sent by any entity of the Dest ID TLV is as defined in network to
indicate the OIF UNI 1.0 [4]
and [5].

3.1.2 CR-LDP desire to terminate an already established call. The
Call Setup Messages

CR-LDP uses the Label Request Release message and a newly defined message, MUST include the Call Setup message, for ID TLV of the call setup. The choice to be
terminated. Confirmation of which message call release is indicated to
use depends on whether the request
initiator using a connection setup is associated Notification message with the
call setup request or not.

3.1.2.1 Label Request Message for appropriate status
code. Reception and processing of the Call Setup

Label Request Release message is used for call setup for those cases where a
connection setup is associated with MUST
trigger the call setup request. The
encoding for release of all connections that are associated to that
call. Connection release follows the normal CR-LDP procedure using
Label Request message for call setup operation 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| Release and Label Request (0x401) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest ID Withdraw messages.

4. CR-LDP TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| for ASON

This section describes the Call ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| and the Call Capability TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other TLVs |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Only TLV that are relevant to the call setup operation are shown
above. Other TLV include those TLV that are relevant to connection
(LSP) setup as defined in [6].

3.1.2.2
introduced for ASON.

4.1 Call Setup Message ID TLV

O. Aboul-Magd Informational- Expires: January March 2003 4

draft-aboulmagd-crldp-ext-ason-00.txt June
Draft-aboulmagd-crldp-ason-ext-01.txt October 2002

An established call may be identified by a Call ID. The Call Setup message ID is a new LDP message
globally unique identifier that is introduced here set by the source network. The
structure for the case where call setup Call ID (to guarantee global uniqueness) is not associated to
concatenate a globally unique fixed identifier (composed of country
code, carrier code, unique access point code) with connection
setup. 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 encoding format of the Call Setup message is: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|
|U|F|Op-Sp Call Setup ID (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call Capability TLV Transport Element Address (STEA Sub TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters Local Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note that unlike the Label Request message, the Call Setup message
does not include any parameters or TLV that are relevant to
connection setup.

3.1.2.3 Call Setup Procedure

The call setup procedure is the same for both messages.

Procedure:
The Calling party initiates a call setup by sending the
appropriate message.

O. Aboul-Magd Informational- Expires: March 2003 5
Draft-aboulmagd-crldp-ason-ext-01.txt October 2002

STEA Sub TLV:
The Call Setup message SHALL contain all the
information required by the network to process the call. In
Particular 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 Transport Element Address is an address of the call.

The Call Setup message shall progress through the
transport network to the
called party. The called party may accept or reject the incoming
call. An LDP Notification message with the appropriate status code
(to be defined) shall be used to inform the calling party whether element (SSN) controlled by the setup is successful. The call source
network. Its length can be rejected by either the
network, e.g. for policy reasons, 4, 6, 16, or by the called party.

3.1.3 CR-LDP Call Release Message

Aboul-Magd Expires: January 2003 5

draft-aboulmagd-crldp-ext-ason-00.txt June 2002 20 byte long. The Call Release message is newly introduced LDP message and STEA
Sub TLV is used
here for call termination independent TLV Type 1.

Local Identifier:
A 64-bit identifier that remains constant over the life of the message used during
call setup.
call.

The encoding format of the Call Release message is: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|
|U|F|GU Call Release ID (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved | Source ID TLV IS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest ID TLV NS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID TLV Source Transport Element Address (STEA sub TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters Local Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Procedure:
The Call Release message is sent by any entity

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 network ITU carrier Code followed by a
Unique Access Point Code.

4.1.1 Call ID Procedure

The following processing rules are applicable to
indicate the desire CALL ID TLV:

- For initial calls, the calling/originating party call controller
must set the CALL ID values to terminate an already established call. The
Call Release message MUST include 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 TLV is non zero) the SNCC
verifies existence of the call to
- The Call ID TLV on all messages MUST be terminated. Confirmation of sent from ingress call release is indicated
controller to egress call controller by all other intermediate
controlling without altering.
- The destination user/client receiving the request initiator using a Notification message with uses the
appropriate status code (to be defined).

Reception CALL ID
values as reference to the requested call between the source user
and processing of itself. Subsequent actions related to the Call Release message MUST trigger call uses the release CALL
ID as the reference identifier.

O. Aboul-Magd Informational- Expires: March 2003 6
Draft-aboulmagd-crldp-ason-ext-01.txt October 2002

4.2 Call Capability TLV

The format of all connections that are associated 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 that call.
Connection release follows explicitly indicate the normal CR-LDP procedure using Label
Release and Label Withdraw messages.

4. CR-LDP Support for
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

Aboul-Magd Expires: January 2003 6

draft-aboulmagd-crldp-ext-ason-00.txt June 2002

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Crankback (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ER-Hop TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Notification message carrying the Crankback TLV may optionally
include a Status TLV indicating the Crankback cause.

In order to avoid a large number of retries, a node may be
configured with a parameter that counts the number of replies until
it reaches a certain allowed maximum. When this maximum value is
reached, no further crankback retries are allowed and the connection
set up fails.

5. CR-LDP Support for SPC

An SPC service assumes that both source and destination user-to-
network connection segments are provisioned while the network
connection segement is set up via the control plane. For example
when the initial request is received from an external source (e.g.,
from 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
SPC in CR-LDP is provided by the introduction of the SPC_Label TLV.
The SPC Label TLV has the same format as the Generalized Label TLV.
The SPC Label Type is TBD.

6. CR-LDP Restart Mechanisms

A number of restart mechanisms was defined for CR-LDP [7, 8]. Any of
those methods could be used here.

It has to be mentioned that in transport network, carriers deploy
high availability equipment that are provisioned with backup copies
of software and hardware. Upon failure a transport equipment should
be able to recover state on its own without relying on its
neighbors. Synchronization with neighbors could be achieved the
resource shortage is identified using
any the ER-HOP TLV. The encoding
of the LDP query-type messages as defined in [5] and [9].

7. CR-LDP 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/Values Codes

G.7713 includes a number of error conditions that are currently
missing from CR-LDP related drafts. 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

O. Aboul-Magd Informational- Expires: January March 2003 7

draft-aboulmagd-crldp-ext-ason-00.txt June
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

8. Summary of CR-LDP Extensions for ASON

6. IANA Consideration

This section summarizes those CR-LDP extensions that are necessary draft uses the LDP RFC 3036 [3] name spaces; see
http://www.iana.org/assignments/ldp-namespaces, which require
assignment for ASON architecture as described in the previous sections.

Two new following messages:

Call Setup and
Call Release

Four new TLV:

The assignment for the following TLVs

Op-Sp Call ID TLV
GU Call ID TLV, TLV
Call Capability TLV, TLV
Crankback TLV, and
SPC Label TLV.

A number of 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 defined listed in section 7 5 of
this draft.

9. Security Considerations

This draft doesn't introduce any new security issues beyond those
identified in CR-LDP RFC.

10. References

1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.

2 M. Mayer, Ed., "Architecture for Automatic Switched Optical Networks
(ASON)", ITU G.8080/Y1304, V1.0, October 2001

3 2001.

2 Z. Lin, Ed., Li, "Distributed Call and Connection Management", ITU
G.7713/Y.1704,
G.7713/Y1704, October 2001

4 Rajagopalan, B. Editor, "User Network Interface (UNI) 1.0
Signaling 2001.

3 L. Andersson,et. al., "LDP Specifications", OIF Contribution, OIF2000.125.7,
October 2001 RFC 3036, January
2001.

O. Aboul-Magd Informational- Expires: January March 2003 8

draft-aboulmagd-crldp-ext-ason-00.txt June
Draft-aboulmagd-crldp-ason-ext-01.txt October 2002

4 B. Rajagopalan "LMP, LDP and RSVP Extensions for Optical UNI
Signaling", draft-oif-uni-signaling-extensions-00.txt, work in
progress, May 2001.

6 Ashoowd-Smith, Jamoussi, Ed., "Constraint-Based LSP Setup Using LDP", RFC
3212, January 2002.

5 P. Ashwood-Smith, et. al., "Generalized MPLS Signaling: CR-LDP Signaling-CR-LDP
Extensions", draft-ietf-mpls-generalized-cr-ldp-05.txt, work in
progress, Nov. 2001 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 A. Farrel, et. al., Fault Tolerance for LDP B. Rajagopalan, "LDP and CR-LDP", draft-
ietf-mpls-ldp-ft-03.txt, work in progress, June 2002.

8 M. Leelanivas, et. al., " Graceful Restart Mechanism RSVP Extensions for LDP"
draft-ietf-mpls-ldp-restart-00.txt, Optical UNI
Signaling" draft-bala-uni-ldp-rsvp-extensions-02.txt, work in
progress, January 2002.

9 P. Ashwood-Smih, et. al., "MPLS LDP Query Message Description",
draft-ietf-mpls-lsp-query-03.txt, work in progress, August 2001.

11. Author's Addresses

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, Ontario, Canada
K1Y-4H7
Tel: + 1 613 763 5827
Phone: 613-599-9104
Email: osama@nortelnetworks.com

O. Aboul-Magd Informational- Expires: January March 2003 9

draft-aboulmagd-crldp-ext-ason-00.txt June
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 be copied and furnished 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 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

O. Aboul-Magd Informational- Expires: January March 2003 10
----