doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc3475.txt b/doc/rfc/rfc3475.txt
new file mode 100644
index 0000000..fde3151
--- /dev/null
+++ b/doc/rfc/rfc3475.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+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: osama@nortelnetworks.com
+
+
+
+
+
+
+
+
+
+
+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]
+