[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 RFC 3475

CCAMP                                                     O. Aboul-Magd
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


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

       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].


O. Aboul-Magd     Informational- Expires: March 2003                 2 

       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

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. 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

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

       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                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


O. Aboul-Magd     Informational- Expires: March 2003                 5 

       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.

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 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

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

       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
      2001.


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

       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 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


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

       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: March 2003                10


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/