Network Working Group                                      O. Aboul-Magd
Request for Comments: 3475                               Nortel Networks
Category: Informational                                       March 2003


                Documentation of IANA assignments for
       Constraint-Based LSP setup using LDP (CR-LDP) Extensions
            for Automatic Switched Optical Network (ASON)

Status of this Memo

  This memo provides information for the Internet community.  It does
  not specify an Internet standard of any kind.  Distribution of this
  memo is unlimited.

Copyright Notice

  Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

  Automatic Switched Optical Network (ASON) is an architecture,
  specified by ITU-T Study Group 15, for the introduction of a 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.

Table of Contents

  1.  Introduction .................................................  2
  2.  Overview of CR-LDP Extensions for ASON .......................  2
  3.  CR-LDP Messages for ASON .....................................  3
     3.1 Call Setup Message ........................................  4
        3.1.2 Call Setup Procedure .................................  5
     3.2 The Call Release Message ..................................  5
        3.2.1 Call Release Procedure ...............................  6
  4.  CR-LDP TLV for ASON ..........................................  6
     4.1 Call ID TLV ...............................................  6
        4.1.1 Call ID Procedure ....................................  8
     4.2 Call Capability TLV .......................................  9



Aboul-Magd                   Informational                      [Page 1]

RFC 3475               CR-LDP Extensions for ASON             March 2003


     4.3 Crankback TLV .............................................  9
  5.  Additional Error Codes ....................................... 10
  6.  IANA Consideration ........................................... 11
  9.  Security Considerations ...................................... 11
  10. Normative References ......................................... 11
  11. Intellectual Property ........................................ 12
  12. Author's Address ............................................. 12
  13. Full Copyright Statement ..................................... 13

1. Introduction

  Automatic Switched Optical Network (ASON) is an architecture,
  specified by ITU-T Study Group 15 (SG15), for the introduction of a
  control plane for optical networks.  The development and the
  standardization of ASON has been done by ITU-T SG15 and is documented
  in recommendation G.8080 [1].  The architecture includes a control
  plane with a set of reference points between the architectural
  components.  The ASON signaling that runs over interfaces defined in
  those reference points are described in ITU-T recommendation G.7713
  [2].

  Constraint-Based LSP Setup using LDP (CR-LDP) [3] is one of the
  protocols selected by 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 ITU-T recommendation G.7713.3 [8].

  This document introduces those CR-LDP extensions that are specific to
  ASON and requests IANA allocation of code points for these
  extensions.  The document does not specify how these extensions are
  used; that is the subject of the above mentioned ITU-T documents.
  This document should be considered in conjunction with RFC 3036 [4],
  RFC 3212 [3], and CR-LDP extensions for GMPLS [5].

2. Overview of CR-LDP Extensions for ASON

  This document 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 controllers as described in G.8080.  Call
  and connection control separation allows for a call with multiple
  connections associated with it.  It also allows for a call with no




Aboul-Magd                   Informational                      [Page 2]

RFC 3475               CR-LDP Extensions for ASON             March 2003


  connections (a temporary situation that might be useful during
  recovery).

  The separation of the call and the connection controllers could be
  achieved using one of two models.  The first model is one where the
  call set up request is always accompanied by a connection request.
  The second model is one in which call set up is done independently
  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.

  A connection set up request must indicate the call to which the
  connection needs to be associated.  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 the 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 CR-LDP label release procedure (using
  LDP Label Release and Label Withdraw messages) as defined in [4].

  A Call Capability TLV is also introduced to explicitly indicate the
  capability of the requested call.

  An Soft Permanent Connection (SPC) service assumes that both source
  and destination user-to-network connection segments are provisioned
  while the network connection segment is set up via the 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 the OIF UNI 1.0 section 11.7.5 [6] from the
  Optical Internetworking Forum and in RFC3476 [7].

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.



Aboul-Magd                   Informational                      [Page 3]

RFC 3475               CR-LDP Extensions for ASON             March 2003


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 (0x0500)        |      Length                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Message ID                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Source ID TLV                       |
     ~                                                               ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Dest ID  TLV                        |
     ~                                                               ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Call ID TLV                         |
     ~                                                               ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Call Capability TLV                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Optional Parameters                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Message ID:
     Is as defined in RFC3036 [4].

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

  Call Capability TLV:
    Is as defined in section 4.2 of this document.








Aboul-Magd                   Informational                      [Page 4]

RFC 3475               CR-LDP Extensions for ASON             March 2003


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 with it.  The Call
  Setup message shall contain all the information required by the
  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 (0x0501)       |      Length                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Message ID                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Source ID TLV                       |
     ~                                                               ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Dest ID TLV                         |
     ~                                                               ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Call ID TLV                         |
     ~                                                               ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Optional Parameters                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+








Aboul-Magd                   Informational                      [Page 5]

RFC 3475               CR-LDP Extensions for ASON             March 2003


3.2.1 Call Release Procedure

  The Call Release message is sent by any entity of the network 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 with that call.  Connection
  release follows the normal CR-LDP procedure using Label Release and
  Label Withdraw messages.

4. CR-LDP TLVs for ASON

  This section describes the operator specific Call ID TLV, the
  globally unique Call ID TLV, the Call Capability TLV and the
  Crankback TLV introduced for ASON.

4.1 Call ID TLV

  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 ingress network element (NE) 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 <NE
  address> plus <local Identifier>).  For a CALL_ID that requires only
  operator specific uniqueness, only the <operator specific Id> is
  needed, while for a CALL_ID that is required 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.










Aboul-Magd                   Informational                      [Page 6]

RFC 3475               CR-LDP Extensions for ASON             March 2003


  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 (0x0831)     |      Length                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   NE Address (NEA Sub TLV)                    |
     ~                                                               ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Local Identifier                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Local Identifier (continued)                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  NEA Sub TLV:
     The Source NE Address is an address of the transport network
     element controlled by the source network.  Its length can be 4, 6,
     16, or 20 bytes long.  The NEA 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 (0x0832)        |      Length                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Reserved      |                    IS                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             NS                                |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   NE Address (NEA Sub TLV)                    |
     ~                                                               ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Local Identifier                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Local Identifier (continued)                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Aboul-Magd                   Informational                      [Page 7]

RFC 3475               CR-LDP Extensions for ASON             March 2003



  International Segment (IS):
     To 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 is based on
     the three-character uppercase alphabetic ISO 3166 Country Code
     (e.g., USA, FRA).

  National Segment (NS):
     The National Segment (NS) field consists of two sub-fields:

        - the first subfield contains the ITU Carrier Code
        - the second subfield contains 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 Bureauin association with Recommendation
     M.1400.  This code consists of 1-6 left-justified alphabetic, or
     leading alphabetic followed by numeric, characters (bytes).  If
     the code is less than 6 characters (bytes), it is padded with a
     trailing NULL to fill the subfield.

     The Unique Access Point Code is a matter for the organization to
     which the country code and ITU carrier code have been assigned,
     provided that uniqueness is guaranteed.  This code consists of 1-6
     characters (bytes), trailing NULL, completing the 12-character
     National Segment.  If the code is less than 6 characters, it is
     padded by a trailing NULL to fill the subfield.

  Format of the National Segment

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       ITU carrier code                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | ITU carrie dode (cont)        |  Unique access point code     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               Unique access point code (continued)            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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.




Aboul-Magd                   Informational                      [Page 8]

RFC 3475               CR-LDP Extensions for ASON             March 2003


  -  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.
  -  Intermediate nodes are not allowed to alter the Call ID TLV set by
     the ingress node.
  -  The destination user/client receiving the request uses the CALL ID
     values as a 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.

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(0x0833)  |      Length                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Call Capability                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The Call Capability TLV contains a 4 byte Call Capability field.  The
  Call Capability Field is used to explicitly indicate the
  configuration potentiality of the call.

  An example of values of the Call Capability field is:

     0x0000   Point to Point 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 Crankback
  TLV is:



Aboul-Magd                   Informational                      [Page 9]

RFC 3475               CR-LDP Extensions for ASON             March 2003


      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(0x0834)         |      Length                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                       ER-HOP TLV                              ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The ER-HOP TLV is specified in rfc3212 [3], and consists of an n x 4
  bytes field, it could e.g. contain an IPv4 or an IPv6 address.

5. Additional Error Codes

  G.7713 includes a number of error codes that are currently not
  defined in earlier CR-LDP related RFCs.  The list of those error
  conditions is given below:

     Invalid SNP ID (0x04000009)
     Calling Party busy (0x0400000a)
     Unavailable SNP ID (0x0400000b)
     Invalid SNPP ID (0x0400000c)
     Unavailable SNPP ID (0x0400000d)

     Failed to create SNC (0x0400000e)
     Failed to establish LC (0x040000f)
     Invalid Source End-User Name (0x04000010)
     Invalid Destination End-User Name (0x04000011)
     Invalid CoS (0x04000012)
     Unavailable CoS (0x04000013)
     Invalid GoS (0x04000014)
     Unavailable GoS (0x04000015)
     Failed Security Check (0x04000016)
     TimeOut (0x04000017)
     Invalid Call Name (0x04000018)
     Failed to Release SNC (0x04000019)
     Failed to Free LC (0x0400001a)

  Acronyms used in above error codes:

     SNP    Sub-network Point
     SNPP   Sub-network Point Pool
     SNC    Sub-network Connection
     LC     Link Connection
     CoS    Class of Service
     GoS    Grade of Service





Aboul-Magd                   Informational                     [Page 10]

RFC 3475               CR-LDP Extensions for ASON             March 2003


6. IANA Consideration

  This document uses the LDP RFC 3036 [4] name spaces; see
  http://www.iana.org/assignments/ldp-namespaces.

     Call Setup (0x0500)
     Call Release (0x0501)

  The assignment for the following TLVs:

     Op-Sp Call ID TLV (0x0831)
     GU Call ID TLV (0x0832)
     Call Capability TLV (0x0833)
     Crankback TLV (0x0834)

  The assignment for the new error codes as listed in section 5 of this
  document.

9. Security Considerations

  This document does not introduce any new security concerns other than
  those defined in RFC 3036 and RFC 3212.

  Security aspects (if any) w.r.t. the G.8080 and G.7713 documents need
  to be addressed in those documents.

10. Normative References

  [1] Architecture for Automatically Switched Optical Network (ASON),
      ITU-T recommendation G.8080, Nov. 2001

  [2] Distributed Call and Connection Management (DCM), ITU-T
      recommendation G.7713, Dec. 2001

  [3] Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu, R., Wu, L.,
      Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M.,
      Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint-Based
      LSP Setup using LDP", RFC 3212, January 2002.

  [4] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B.
      Thomas, "LDP Specifications", RFC 3036, January 2001.

  [5] Ashwood-Smith, P. and L. Berger, (Editors),"Generalized Multi-
      Protocol Label Switching (GMPLS) Signaling Constraint-based
      Routed Label Distribution Protocol (CR-LDP) Extensions", RFC
      3472, January 2003.





Aboul-Magd                   Informational                     [Page 11]

RFC 3475               CR-LDP Extensions for ASON             March 2003


  [6] UNI 1.0 Signaling Specification, The Optical Internetworking
      Forum, http://www.oiforum.com/public/UNI_1.0_ia.html

  [7] Rajagopalan, B., "Label Distribution Protocol (LDP) and Resource
      ReserVation Protocol (RSVP) Extensions for Optical UNI
      Signaling", RFC 3476, March 2003.

  [8] Distributed Call and Connection Management signalling using GMPLS
      CR-LDP, ITU G.7713.3, Januray 2003.

11. Intellectual Property

  The IETF takes no position regarding the validity or scope of any
  intellectual property or other rights that might be claimed to
  pertain to the implementation or use of the technology described in
  this document or the extent to which any license under such rights
  might or might not be available; neither does it represent that it
  has made any effort to identify any such rights.  Information on the
  IETF's procedures with respect to rights in standards-track and
  standards-related documentation can be found in RFC 2028.  Copies of
  claims of rights made available for publication and any assurances of
  licenses to be made available, or the result of an attempt made to
  obtain a general license or permission for the use of such
  proprietary rights by implementors or users of this specification can
  be obtained from the IETF Secretariat.

  The IETF invites any interested party to bring to its attention any
  copyrights, patents or patent applications, or other proprietary
  rights which may cover technology that may be required to practice
  this standard.  Please address the information to the IETF Executive
  Director.

12. Author's Addresses

  Osama Aboul-Magd
  Nortel Networks
  P.O. Box 3511, Station C
  Ottawa, Ontario, Canada
  K1Y 4H7
  Phone: 613-599-9104
  EMail: [email protected]










Aboul-Magd                   Informational                     [Page 12]

RFC 3475               CR-LDP Extensions for ASON             March 2003


13. Full Copyright Statement

  Copyright (C) The Internet Society (2003).  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 implementation 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 languages other than
  English.

  The limited permissions granted above are perpetual and will not be
  revoked by the Internet Society or its successors or assigns.

  This document and the information contained herein is provided on an
  "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

  Funding for the RFC Editor function is currently provided by the
  Internet Society.



















Aboul-Magd                   Informational                     [Page 13]