CCAMP WG O. Aboul-Magd
Internet Draft Nortel Networks
Document: draft-aboulmagd-ccamp-crldp-ason-ext-00.txt
June 2002
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].
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 for the support of the ITU
ASON architecture (G.8080) [2] and its signaling requirements
(G.7713) [3].
The CCAMP WG charter includes the statement:
"Define signalling protocols and measurement protocols such 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 is within the CCAMP charter since it defines extensions
to a CCAMP-defined signaling protocol, namely CR-LDP, for transport
network tunnels.
2. Introduction
During the IETF meeting in Minneapolis March 2002, an ITU liasian
was presented requesting that IETF CCAMP WG to consider extensions
for the GMPLS suite of signaling protocols for ASON network
architecture [2] and its signaling requirements [3].
Aboul-Magd Expires January 2003 1
draft-aboulmagd-crldp-ext-ason-00.txt June 2002
The liaison identifies five areas where extensions are needed to
meet ASON signaling requirements. Those areas are:
a. Call and connection control separation
b. Additional Error Codes/Values
c. Restart Mechanism
d. Support for Crankback
e. Support for 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 important architecture principle of ASON is that call and
connection control are treated separately. With this separation
there could be the case where a single call has one or more
connections associated to it. It is also quite possible to have a
call with no connections associated to it, for example during
recovery times.
The current set of GMPLS signaling protocols, i.e. CR-LDP and RSVP-
TE do not support this requirement. In reality the notion of 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 the subject of some
discussion at ITU. Those cases are:
a. A call setup is always accompanied by a connection setup. This
case is sometimes referred to as "logical separation"
b. A call setup is done separately from connection setup. In this
case call setup is mainly for the exchange of call control
information between the two end points of a call. This case is
sometimes referred to as "complete separation"
In both cases connections associated with the call could be setup or
torn down after the successful set up of the call. Furthermore the
release of a call should result in clearing of all the connection
associated with it.
3.1 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 cases
mentioned above. In the case where the call setup request is always
accompanied by a connection setup, the same LDP message used for
connection setup (Label Request) is at the same time used for call
setup.
For the other cases where a call setup is done independently from
the connection setup, a new LDP message (Call Setup) is introduced.
The introduction of a new message is justified by the observation
that the existing LDP messages perform procedures at the connection,
or LSP, level. In this case the setup of a call doesn't include any
of those procedure. Thus a new message is justified to avoid the
inevitable overloading of the semantics of existing messages.
3.1.1 TLV Encodings for Call Operation
This section describes the encoding for new TLV required for call
setup. Two new TLV are introduced. Those are Call ID TLV and Call
Capability TLV. Other TLV that are required for call operation are
the Source ID TLV and the Dest ID TLV (Src ID and Dest ID TLV 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 and connection
control environment.
The format of the Call ID 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 ID (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Call ID has a minimum length of 32 bits.
3.1.1.2 Call Capability TLV
The Call Capability (Call Cap) TLV is used to explicitly indicate
the configuration of potentiality of the call, e.g. pt-to-pt call.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Aboul-Magd Expires: January 2003 3
draft-aboulmagd-crldp-ext-ason-00.txt June 2002
|U|F| Call Cap (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.1.3 Source ID TLV
The format of the Source ID TLV is as defined in the OIF UNI 1.0 [4]
and [5]
3.1.1.4 Dest ID TLV
The format of the Dest ID TLV is as defined in the OIF UNI 1.0 [4]
and [5].
3.1.2 CR-LDP Call Setup Messages
CR-LDP uses the Label Request message and a newly defined message,
Call Setup message, for call setup. The choice of which message to
use depends on whether a connection setup is associated with the
call setup request or not.
3.1.2.1 Label Request Message for Call Setup
Label Request message is used for call setup for those cases where a
connection setup is associated with the call setup request. The
encoding for the 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| Label Request (0x401) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Call Setup Message
Aboul-Magd Expires: January 2003 4
draft-aboulmagd-crldp-ext-ason-00.txt June 2002
The Call Setup message is a new LDP message that is introduced here
for the case where call setup is not associated with connection
setup. The encoding 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. 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 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
(to be defined) 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.1.3 CR-LDP Call Release Message
Aboul-Magd Expires: January 2003 5
draft-aboulmagd-crldp-ext-ason-00.txt June 2002
The Call Release message is newly introduced LDP message and is used
here for call termination independent of the message used during
call setup. The encoding 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (to be defined).
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 Support for Crankback
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 using
any of the LDP query-type messages as defined in [5] and [9].
7. CR-LDP Additional Error Codes/Values
G.7713 includes a number of error conditions that are currently
missing from CR-LDP related drafts. 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
Aboul-Magd Expires: January 2003 7
draft-aboulmagd-crldp-ext-ason-00.txt June 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
This section summarizes those CR-LDP extensions that are necessary
for ASON architecture as described in the previous sections.
Two new messages: Call Setup and Call Release
Four new TLV: Call ID TLV, Call Capability TLV, Crankback TLV, and
SPC Label TLV.
A number of new error codes as defined in section 7
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 Z. Lin, Ed., "Distributed Call and Connection Management", ITU
G.7713/Y.1704, October 2001
4 Rajagopalan, B. Editor, "User Network Interface (UNI) 1.0
Signaling Specifications", OIF Contribution, OIF2000.125.7,
October 2001
Aboul-Magd Expires: January 2003 8
draft-aboulmagd-crldp-ext-ason-00.txt June 2002
5 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, P. et. al., "Generalized MPLS Signaling: CR-LDP
Extensions", draft-ietf-mpls-generalized-cr-ldp-05.txt, work in
progress, Nov. 2001
7 A. Farrel, et. al., Fault Tolerance for LDP and CR-LDP", draft-
ietf-mpls-ldp-ft-03.txt, work in progress, June 2002.
8 M. Leelanivas, et. al., " Graceful Restart Mechanism for LDP"
draft-ietf-mpls-ldp-restart-00.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
Email: osama@nortelnetworks.com
Aboul-Magd Expires: January 2003 9
draft-aboulmagd-crldp-ext-ason-00.txt June 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
Aboul-Magd Expires: January 2003 10