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

Versions: (draft-dimitri-ccamp-gmpls-rsvp-te-ason) 00 01 02 03 04

CCAMP Working Group                                   J. Drake (Boeing)
Internet Draft                               D. Papadimitriou (Alcatel)
Proposed Category: Standard Track        A. Farrel (Old Dog Consulting)
                                                      D. Brungard (ATT)
                                                         Z. Ali (Cisco)
                                                  A. Ayyangar (Juniper)
                                                H. Ould-Brahim (Nortel)
                                                      D. Fedyk (Nortel)

Expiration Date: January 2006                                 July 2005


                Generalized MPLS (GMPLS) RSVP-TE Signalling
        in support of Automatically Switched Optical Network (ASON)

                draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on January 19, 2006.

Copyright Notice

      Copyright (C) The Internet Society (2005).

Abstract

   This document specifies how Generalized MPLS (GMPLS) RSVP-TE
   signaling may be used and extended to satisfy the requirements of the
   Automatically Switched Optical Network (ASON) architecture specified
   by the ITU-T. The requirements are in a companion document
   "Requirements for Generalized MPLS (GMPLS) Usage and Extensions for
   Automatically Switched Optical Network (ASON)."

D.Papadimitriou et al. - Expires January 2006                        1
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005



   In particular, this document details the mechanisms for setting up
   Soft Permanent Connections (SPC), the necessary extensions in
   delivering full and logical call/connection separation support, the
   extended restart capabilities during control plane failures, extended
   label usage and crankback signalling capability.

   The mechanisms proposed in this document are applicable to any
   environment (including multi-area) and for any type of interface:
   packet, layer-2, time-division multiplexed, lambda or fiber
   switching.

1. Table of Content

   Abstract ......................................................... 1
   1. Table of Content .............................................. 2
   2. Conventions used in this document ............................. 3
   3. Introduction .................................................. 3
   3.1 Comparison with Previous Work ................................ 4
   3.2 Applicability ................................................ 5
   3.2.1 Network-Network Interface (I-NNI and E-NNI) ................ 6
   3.2.2 User-Network Interface (UNI) ............................... 8
   4. Fulfilling ASON Requirements for GMPLS Signaling .............. 8
   4.1 Soft Permanent Connection (SPC) .............................. 8
   4.2 Call/Connection Separation  .................................. 8
   4.3 Call Segments ................................................ 9
   4.4 Control Plane Restart Capabilities ........................... 9
   4.5 Extended Label Association ................................... 9
   4.6 Crankback Signaling .......................................... 9
   4.7 Additional Error Codes ....................................... 9
   5. Concepts and Terms ........................................... 10
   5.1 What is a Call? ............................................. 10
   5.2 Hierarchy of Calls, Connections, Tunnels and LSPs ........... 10
   5.3 Exchanging Access Link Capabilities ......................... 10
   5.3.1 Network-initiated Calls ................................... 11
   5.3.2 User-initiated Calls ...................................... 11
   5.3.3 Utilizing Call Setup ...................................... 11
   6. Protocol Extensions for Calls and Connections ................ 11
   6.1 Call Identification ......................................... 11
   6.1.1 Long Form Call Identification ............................. 12
   6.1.2 Short Form Call Identification ............................ 12
   6.1.3 Short Call ID Encoding .................................... 13
   6.2 LINK_CAPABILITY Object ...................................... 14
   6.3 Revised Message Format ...................................... 14
   6.3.1 Notify Message ............................................ 15
   6.4 ADMIN_STATUS Object ......................................... 15
   7. Procedures in Support of Call and Connections ................ 16
   7.1 Call/Connection Setup Procedures ............................ 16
   7.2 Independent Call Setup ...................................... 17
   7.2.1 Accepting Independent Call Setup .......................... 18
   7.2.2 Rejecting Independent Call Setup .......................... 19
   7.3 Adding a Connection to a Call ............................... 19
   7.3.1 Adding a Reverse Direction Connection to a Call ........... 20

D.Papadimitriou et al. - Expires January 2006                        2
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


   7.4 Simultaneous Call/Connection Setup .......................... 20
   7.4.1 Accepting Simultaneous Call/Connection Setup .............. 20
   7.4.2 Rejecting Simultaneous Call/Connection Setup .............. 21
   7.5 Call-Free Connection Setup .................................. 21
   7.6 Call Collision .............................................. 21
   7.7 Call/Connection Teardown .................................... 22
   7.7.1 Removal of a Connection from a Call ....................... 22
   7.7.2 Removal of the Last Connection from a Call ................ 23
   7.7.3 Teardown of an "Empty" Call ............................... 23
   7.7.4 Teardown of a Call with Existing Connections .............. 23
   7.7.5 Teardown of a Call from the Egress ........................ 23
   7.8 Control Plane Survivability ................................. 24
   8. Applicability of Call and Connection Procedures .............. 25
   8.1 Network-initiated Calls ..................................... 25
   8.2 User-initiated Calls ........................................ 25
   8.3 External Call Managers ...................................... 26
   8.3.1 Call Segments ............................................. 26
   9. Non-support of Call ID ....................................... 26
   9.1 Non-support by External Call Managers ....................... 26
   9.2 Non-support by Transit Nodes ................................ 27
   9.3 Non-support by Egress Nodes ................................. 27
   10. Security Considerations ..................................... 28
   10.1 Call and Connection Security Considerations ................ 28
   11. IANA Considerations ......................................... 28
   12. Acknowledgements ............................................ 29
   13. References .................................................. 29
   13.1 Normative References ....................................... 30
   13.2 Informative References ..................................... 30
   14. Author's Addresses .......................................... 31
   Appendix 1. Analysis of G.7713.2 against GMPLS RSVP-TE Signaling
   Requirements in Support of ASON.................................. 32

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   In addition, the reader is assumed to be familiar with the
   terminology used in [RFC3471], [RFC3473], [RFC3477] and [RFC3945].

3. Introduction

   This document describes how GMPLS RSVP-TE signaling [RFC3473] can be
   used and extended in support of Automatically Optical Switched
   Networks (ASON) as specified in the ITU-T G.8080 recommendation
   [G.8080]. Note, however, that the mechanisms that it describes and
   references have a larger scope than the one described in this
   document.

   [ASON-REQ] identifies the requirements to be covered by the
   extensions to the GMPLS signaling protocols to support the
   capabilities of an ASON network.

D.Papadimitriou et al. - Expires January 2006                        3
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005



   The following are expected from the GMPLS protocol suite to realize
   the needed ASON functionality:
   a) support for soft permanent connection functionality
   b) support for call and connection separation
   c) support for call segments
   d) support for extended restart capabilities during control plane
      failures
   e) support for extended label association
   f) support for crankback capability.

   This document is aligned with the [RSVP-CHANGE] process, which
   requires evaluation of existing protocol functionality for achieving
   the requested functionality and justification for any requested
   changes or new extensions. In this context, the following summarizes
   the evaluation made:

   1. Signaling across the internal network-network interface (I-NNI)
      and user-network interface (UNI) can be done as described in
      [RFC3473] and [GMPLS-OVERLAY] respectively. Thus, the processing
      of standard objects and functions (such as EXPLICIT_ROUTE Object
      and RECORD_ROUTE Object) are as described in those documents.

   2. The second is that any GMPLS RSVP-TE object, message or procedure
      not defined in this document or in a directly referenced document
      is handled exactly as described in [RFC3473], [RFC3209],
      [RFC2961], and [RFC2205]. An important consideration is that the
      procedures introduced by this document do not introduce any
      forward or backward compatibility issue.

   3. The mechanisms proposed in this document are not restricted to
      LSC or TDM capable interfaces, but are equally applicable to any
      packet (PSC) or layer-2 interfaces (L2SC). As a consequence, the
      present document proposes ubiquitously applicable RSVP
      extensions.

3.1 Comparison with Previous Work

   Informational RFC [RFC3474] documents the code points for the
   signaling extensions defined in [G.7713.2] to meet the requirements
   of ASON Distributed Call and Connection Management (DCM) as specified
   in [G.7713].

   While [G.7713.2] make use of GMPLS RSVP-TE signaling, there are key
   differences from the problem statement in [ASON-REQ] and the solution
   it provides. These differences result from the development of a
   fuller and clearer set of requirements in [G.8080] after the time
   that [G.7713.2] was published and [ASON-REQ] considerations for
   compatibility aspects with GMPLS [RFC3473]. These differences are
   enumerated below and detailed in Appendix 1.

   1. As described in [G.8080], there are various models and multiple
      methods of achieving connections across multiple domains.

D.Papadimitriou et al. - Expires January 2006                        4
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


      [G.7713.2] is similar to a cooperative connection model between
      domains, that is, there is no overall coordination, and it uses
      point-to-point external NNI (E-NNI) signaling between inter-
      domain border controllers (i.e. single-hop LSP). Additionally, it
      requires address resolution at both border controllers regardless
      of the address space used. Recent enhancements to [G.8080]
      include end-to-end network capabilities based on flexible (end-
      to-end) path selection to support optimal route selection i.e.
      source-based re-routing and crankback.

      To provide for these enhancements and future capabilities (e.g.,
      VPNs), [ASON-REQ] is based on an inter-domain model using an end-
      to-end call model, modeling multiple domains as one virtual
      network, and optional one-time (ingress) address resolution
      (optional, if multiple address families are needed). Note that
      this model is the same model used by [RFC3471], [RFC3473] and
      [GMPLS-OVERLAY].

   2. [G.7713.2] distinguishes between use of [G.7713.2] for ASON
      networks and use of [RFC3473] for GMPLS networks; however, no
      compatibility aspects are addressed. [ASON-REQ] addresses ASON
      requirements for GMPLS networks. Backward compatibility allows
      for the coexistence of nodes supporting GMPLS RSVP-TE [RFC3473]
      with nodes supporting GMPLS RSVP-TE for ASON (as described in
      this document).

      [ASON-REQ] requires that for any new and existing GMPLS features,
      [RFC3473] transit nodes do not need to be updated and do not need
      to modify their behavior to support the end-to-end features of
      ASON. The solution provided by [G.7713.2] is not backward
      compatible with [RFC3473]. Moreover, [G.7713.2] can not be used
      in a network with [RFC3473], as incorrect network behavior will
      result.

   3. While existing GMPLS signalling [RFC3473] supports Soft Permanent
      Connections (SPCs), [G.7713.2] defines a new mechanism to support
      SPCs, and this new mechanism is incompatible with [RFC3473].

   4. [G.7713.2] does not support full call and connection separation,
      multiple connections per call, or ingress/egress node capability
      negotiation prior to connection establishment.

   5. [G.7713.2] does not support call segment signaling mechanisms, as
      required in [G.8080] and [G.7713].

   6. [G.7713.2] defines control plane restart capabilities that are
      incompatible with those described in [RFC3473].

   7. [G.7713.2] does not support crankback signaling mechanisms
      [GMPLS-CRANK], as required in [G.8080] and [G.7713].

3.2 Applicability


D.Papadimitriou et al. - Expires January 2006                        5
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


   The requirements placed on the signaling plane of an optical network
   to support the capabilities of an Automatically Switched Optical
   Network (see [ASON-REQ]) apply at both the network-network interface
   (NNI) and the user-network interface (UNI).

   Some extensions to the core signaling features (see [RFC3473]) are
   required in support of some of the ASON requirements. [GMPLS-OVERLAY]
   defines a common set of standard procedures at the user-network
   interface (UNI). Other documents referenced in specific subsections
   of this document define specific protocol extensions in support of
   specific ASON requirements.

3.2.1 Network-Network Interface (I-NNI and E-NNI)

   At the NNI, the ingress and egress core nodes play a full part in the
   GMPLS network from a signaling point of view. Applicability of GMPLS
   RSVP-TE signaling at the I-NNI is implicitly detailed in [RFC3471]
   and [RFC3473]. Routing information is fully or partially distributed
   through this multi-vendor interface.

   The following paragraphs further detail the applicability of
   [RFC3471] and [RFC3473] mechanisms at the E-NNI. Note also that the
   use of these RFCs at the E-NNI does not preclude the use of another
   signaling protocol for the I-NNI as long as an inter-working function
   is provided by the non-GMPLS domain. Routing information may be fully
   or partially distributed through this interface.

   The basic GMPLS RSVP-TE operations at the E-NNI reference point
   involves (as inspired from [GMPLS-OVERLAY]):

   1. Addressing

   Two adjacent egress/ingress core nodes must share the same address
   space, which is used by GMPLS E-NNI signaling. A set of egress/
   ingress core node tuples share the same address space if the ingress
   or ingress core node in the set could exchange GMPLS RSVP-TE messages
   among themselves. Within a control domain, the address space used by
   the core nodes to communicate among themselves MAY, but need not be
   shared with the address space used by any of the egress/ingress core
   node tuples.

   A core node is identified by either a single IP address representing
   its Node ID, or by one or more un/numbered TE links that interconnect
   core-nodes. A core node needs only to know (and track) the interface
   addresses and/or Node IDs of client nodes to which incoming messages
   are directed.

   Links may be either numbered or unnumbered. Further, links may be
   bundled or unbundled. See [BUNDLE] and [RFC3477], respectively.
   (IF_ID) RSVP_HOP object processing at E-NNI boundaries follows the
   rules defined in [RFC3473].
   2. ERO Processing


D.Papadimitriou et al. - Expires January 2006                        6
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


   An ingress core node MAY receive and potentially reject a Path
   message that contains an ERO. Such behavior is controlled by
   (hopefully consistent) configuration. If an ingress core node rejects
   a Path message due to the presence of an ERO it SHOULD return a
   PathErr message with an error code of "Unknown object class" toward
   the sender. This causes the path setup to fail.

   Further an ingress core node MAY accept EROs that include a sequence
   of [<egress core node, ingress core node>]. This is to support
   explicit label control on the egress core node interface. Incoming
   EROs may also include a combination of the latter with sequence of
   loose ingress core node addresses and/or AS numbers. If an ingress
   core node rejects a Path message due to the presence of an ERO not of
   the permitted format it SHOULD return a PathErr message with an error
   code of Bad Explicit Route Object as defined in [RFC3209].

   - Path Message without ERO: when an ingress core node receives a Path
     message from an egress core node that contains no ERO, it MUST
     calculate a route to the destination and include that route in a
     ERO, before forwarding the PATH message. One exception would be if
     the egress core node were also adjacent to this core node. If no
     route can be found, the ingress core node SHOULD return a PathErr
     message with an Error code and value of 24,5 - "No route available
     toward destination".

   - Path Message with ERO: when an ingress core node receives a Path
     message from an egress core node that contains an ERO, the ingress
     core node SHOULD verify the route against its topology database
     before forwarding the PATH message. If the route is not viable,
     then a PathErr message with an error code and value of 24,5 - "No
     route available toward destination" should be returned.

   3. RRO Processing

   An egress or an ingress core node MAY include an RRO and MAY remove
   the RRO from the received Path message before forwarding it. Further
   an egress or an ingress core node MAY remove the RRO from a Resv
   message before forwarding it. Such behavior is controlled by
   (hopefully consistent) configuration.

   Further an ingress core node MAY edit the RRO in a Resv message such
   that it includes only the subobjects from the egress core node
   through the ingress core node of a neighboring E-NNI. This is to
   allow the ingress core node to be aware of the selected link and
   labels on the far end of the connection traversing this network.

   4. Notification

   An ingress core node MAY include a NOTIFY_REQUEST object in both the
   Path and Resv messages it forwards. An ingress node MAY remove the
   NOTIFY_REQUEST object from the Path and Resv message before
   forwarding it. An egress node MAY remove the NOTIFY_REQUEST object
   from the Path and Resv message before forwarding it. Core nodes may

D.Papadimitriou et al. - Expires January 2006                        7
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


   send Notification messages to ingress/egress core nodes, which have
   included the NOTIFY_REQUEST object.

   Note: the use of the Notify message for independent Call setup as
   defined in this document extends the one specified in [RFC-3473].

3.2.2 User-Network Interface (UNI)

   At the UNI, the ingress and/or the egress nodes are not full players
   in the GMPLS network. Signaling information may be filtered and
   substituted by the network. This process is described in [GMPLS-
   OVERLAY]. Routing information leaked to the ingress/egress nodes is
   very limited.

   The ingress node may initiate an LSP setup/teardown request to the
   network using standard GMPLS procedures. The modifications to
   behavior described in [GMPLS-OVERLAY] apply to the nodes within the
   network (in particular, the network edge nodes) and not ingress or
   egress nodes.

4. Fulfilling ASON Requirements for GMPLS Signaling

   This section briefly describes how the requirements identified in
   [ASON-REQ] are met by existing GMPLS specifications, by procedures
   described in this document, or by other means.

4.1 Soft Permanent Connection (SPC)

   A Soft Permanent Connection (SPC) is defined as a combination of a
   permanent connection at the network edges and a switched connection
   within the network.

   SPC setup is provided using Explicit Label Control as specified in
   [RFC3473], with the augmented procedures described in [GMPLS-
   OVERLAY].

4.2 Call/Connection Separation

   The call concept for optical networks is defined in [G.8080] where it
   is used to deliver the following capabilities:

   - Verification and identification of the call initiator (prior to
     LSP setup)

   - Support of virtual concatenation with diverse path component LSPs

   - Multiple LSP association with a single call (note aspects related
     to recovery are detailed in [GMPLS-FUNCT] and [GMPLS-E2E])

   - Facilitate control plane operations by allowing operational status
     change of the associated LSP.



D.Papadimitriou et al. - Expires January 2006                        8
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


   Procedures and protocol extensions to support Call setup, and the
   association of Calls with Connections are described in sections 5 and
   onwards of this document.

4.3 Call Segments

   Call segments capabilities MUST be supported by both independent call
   setup and simultaneous call/connection setup.

   Procedures and (GMPLS) RSVP-TE signaling protocol extensions to
   support call segments are described in sections 8.4.1 of this
   document.

4.4 Control Plane Restart Capabilities

   Restart capabilities are provided by GMPLS RSVP-TE signaling in case
   of control plane failure including nodal and control channel faults.
   The handling of node and control channels faults is described in
   [RFC3473] Section 9. No additional RSVP mechanisms or objects are
   required to fulfill the ASON control plane restart capabilities.

   However, it should be noted that restart considerations must form
   part of each of the procedures referenced from or described in this
   document.

4.5 Extended Label Association

   Dynamic discovery of label associations as described in [ASON-REQ]
   can be either performed through manual provisioning or using the Link
   Management Protocol [LMP] capabilities.

4.6 Crankback Signaling

   Crankback signaling allows a connection setup request to be retried
   on an alternate path that detours around a blocked link or node upon
   a setup failure, for instance, because a link or a node along the
   selected path has insufficient resources. Crankback mechanisms may
   also be applied during connection recovery by indicating the location
   of the failed link or node. This would significantly improve the
   successful recovery ratio for failed connections, especially in
   situations where a large number of setup requests are simultaneously
   triggered.

   Crankback mechanisms for (GMPLS) RSVP-TE signaling are covered in a
   dedicated companion document [GMPLS-CRANK]. That document is intended
   to fulfill all the corresponding ASON requirements as well as
   satisfying any other crankback needs.

4.7 Additional Error Codes

   Error codes corresponding to the mechanisms defined in this document
   are specified along each section and summarized in Section 11.


D.Papadimitriou et al. - Expires January 2006                        9
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


5. Concepts and Terms

   The concept of a Call and a Connection are discussed in the ASON
   architecture [G.8080]. This section is not intended as a substitute
   for that document, but is a brief summary of the key terms and
   concepts.

5.1 What is a Call?

   A Call is an agreement between endpoints possibly in cooperation with
   the nodes that provide access to the network. Call setup may include
   capability exchange, policy, authorization and security.

   A Call is used to facilitate and manage a set of Connections that
   provide end to end data services. While Connections require state to
   be maintained at nodes along the data path within the network, Calls
   do not involve the participation of transit nodes except to forward
   the Call management requests as transparent messages.

   A Call may be established and maintained independently of the
   Connections that it supports.

5.2 A Hierarchy of Calls, Connections, Tunnels and LSPs

   Clearly there is a hierarchical relationship between Calls and
   Connections. One or more Connections may be associated to a Call. A
   Connection may not be part of more than one call. A Connection may,
   however, exist without a Call.

   In GMPLS RSVP-TE [RFC3473], a Connection is identified with a GMPLS
   TE Tunnel. Commonly a Tunnel is identified with a single LSP, but it
   should be noted that for protection, load balancing and many other
   functions, a Tunnel may be supported by multiple parallel LSPs. The
   following identification reproduces this hierarchy:

   - Call IDs are unique within the context of the pair of addresses
     that are the source and destination of the Call.

   - Tunnel IDs are unique within the context of the Session (that is
     the destination of the Tunnel). Applications may also find it
     convenient to keep the Tunnel ID unique within the context of a
     Call.

   - LSP IDs are unique within the context of a Tunnel.

   Note that the Call_ID value of zero is reserved and MUST NOT be used
   during LSP-independent call establishment.

   Throughout the remainder of this document, the terms LSP and Tunnel
   are used interchangeably with the term Connection. The case of a
   Tunnel that is supported by more than one LSP is covered implicitly.



D.Papadimitriou et al. - Expires January 2006                       10
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


5.3 Exchanging Access Link Capabilities

   It is useful for the ingress node of an LSP to know the link
   capabilities of the link between the network and the egress node.
   This information may allow the ingress node to tailor its LSP request
   to fit those capabilities and to better utilize network resources
   with regard to those capabilities.

   In particular, this may be used to achieve end-to-end spectral
   routing attribute negotiation for signal quality negotiation (such as
   BER) in photonic environments where network edges are signal
   regeneration capable. Similarly, it may be used to provide end-to-end
   spatial routing attribute negotiation in multi-area routing
   environments, in particular, when TE links have been bundled based on
   technology specific attributes.

   Call setup may provide a suitable mechanism to exchange information
   for this purpose, although several other possibilities exist.

5.3.1 Network-initiated Calls

   In this case, there may be no need to distribute additional link
   capability information over and above the information distributed by
   the TE and GMPLS extensions to the IGP. Further, it is possible that
   future extensions to these IGPs will allow the distribution of more
   detailed information including optical impairments.

5.3.2 User-initiated Calls

   In this case, edge link information may not be visible within the
   core network, nor (and specifically) at other edge nodes. This may
   prevent an ingress from requesting suitable LSP characteristics to
   ensure successful LSP setup.

   Various solutions to this problem exist including the definition of
   static TE links (that is, not advertised by a routing protocol)
   between the core network and the edge nodes. Nevertheless, special
   procedures may be necessary to advertise edge TE link information to
   the edge nodes outside of the network without advertising the
   information specific to the contents of the network.

   In the future, when the requirements are understood on the
   information that needs to be supported, TE extensions to EGPs may be
   defined that provide this function.

5.3.3 Utilizing Call Setup

   When IGP and EGP solutions are not available at the UNI, there is
   still a requirement to have, at the local edge nodes, the knowledge
   of the remote edge link capabilities.

   The Call setup procedure provides an opportunity to discover edge
   link capabilities of remote edge nodes before LSP setup is attempted.

D.Papadimitriou et al. - Expires January 2006                       11
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


   The LINK CAPABILITY object is defined to allow this information to be
   exchanged. The information that is included in this object is similar
   to that distributed by GMPLS-capable IGPs (see [GMPLS-RTG]).

6. Protocol Extensions for Calls and Connections

   This section describes the protocol extensions needed in support of
   Call identification and management of Calls and Connections.
   Procedures for the use of these protocol extensions are described in
   section 7.

6.1 Call Identification

   As soon as the concept of a call is introduced, it is necessary to
   support some means of identifying the call. This becomes particularly
   important when calls and connections are separated and connections
   must contain some reference to the call.

   According to [ASON-REQ], a call may be identified by a sequence of
   bytes that may have considerable (but not arbitrary) length. A Call
   ID of 40 bytes would not be unreasonable. It is not the place of this
   document to supply rules for encoding or parsing Call IDs, but it
   must provide a suitable means to communicate Call IDs within the
   protocol. The full call identification as required by ASON is
   referred to as the long Call ID.

   The Call_ID is only relevant at the sender and receiver nodes.
   Maintenance of this information in the signaling state is not
   mandated at any intermediate node. Thus no change in [RFC3473]
   transit implementations is required and there are no backward
   compatibility issues. Forward compatibility is maintained by using
   the existing default values to indicate that no Call processing is
   required.

6.1.1 Long Form Call Identification

   The "Session Name" attribute of the SESSION_ATTRIBUTE Object is used
   to carry the long form of the Call ID.

   A unique value per call is inserted in the "Session Name" field by
   the initiator of the call. Subsequent network nodes MAY inspect this
   object and MUST forward this object transparently across network
   interfaces until reaching the egress node. Note that the structure of
   this field MAY be the object of further formatting depending on the
   naming convention(s). However, [RFC3209] defines the "Session Name"
   field as a Null padded display string, and that any formatting
   conventions for the Call ID must be limited to this scope.

6.1.2 Short Form Call Identification

   The connections (LSPs) associated with a call need to carry a
   reference to the call - the Call ID. Each LSP MAY carry the full long
   Call ID in the "Session Name" of the SESSION ATTRIBUTE object to

D.Papadimitriou et al. - Expires January 2006                       12
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


   achieve this purpose. However, existing (and future) implementations
   may need to place other strings in this field (in particular, the
   field is currently intended to provide the Session Name). To allow
   for this possibility a new field is added to the signaling protocol
   to identify an individual LSP with the Call to which it belongs.

   The new field is a 16-bit identifier (unique within the context of
   the address pairing provided by the Tunnel_End_Point_Address and the
   Sender_Address) that MUST be exchanged during Call initialization and
   is used on all subsequent LSP setups that are associated with the
   Call. This identifier is known as the short Call ID and is encoded as
   described in Section 6.1.3. When relevant, the Call Id MUST NOT be
   used as part of the processing to determine the session to which an
   RSVP signaling message applies. This does not generate any backward
   compatibility issue since the reserved field of the SESSION object
   defined in [RFC3209] MUST NOT be examined on receipt.

   In the unlikely case of short Call_ID exhaustion, local node policy
   decides upon specific actions to be taken. Local policy details are
   outside of the scope of this document.

6.1.3 Short Form Call ID Encoding

   The short Call ID is carried in a 16-bit field in the SESSION object
   used during Call and LSP setup. The field used was previously
   reserved (MUST be set to zero on transmission and ignored on
   receipt). This ensures backward compatibility with nodes that do not
   utilize calls.

   The figure below shows the new version of the object.

   Class = SESSION, Class-Num = 1, C-Type = 7(IPv4)/8(IPv6)

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               IPv4/IPv6 Tunnel end point address              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Call_ID            |           Tunnel ID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Extended Tunnel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4/IPv6 Tunnel End Point Address: 32 bits/128 bits (see [RFC3209])

   Call_ID: 16 bits

        A 16-bit identifier used in the SESSION object that remains
        constant over the life of the call. The Call_ID value MUST be
        set to zero when there is no corresponding call.

   Tunnel ID: 16 bits (see [RFC3209])


D.Papadimitriou et al. - Expires January 2006                       13
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


   Extended Tunnel ID: 32 bits/128 bits (see [RFC3209])

6.2 LINK_CAPABILITY object

   The LINK CAPABILITY object is introduced to support link capability
   exchange during Call setup. This optional object includes the bundled
   link local capabilities of the call initiating node (or terminating
   node) indicated by the source address of the Notify message.

   The Class Number is selected so that the nodes that do not recognize
   this object drop it silently. That is, the top bit is set and the
   next bit is clear.

   This object has the following format:

   Class-Num = TBA (form 10bbbbbb), C_Type = 1

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     //                        (Subobjects)                          //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The contents of the LINK_CAPABILITY object is defined as series of
   variable-length data items called subobjects. The subobject format is
   defined in [RFC3209].

   The following subobjects are currently defined:
   - Type 1: the link local IPv4 address (numbered bundle) using the
     format defined in [RFC3209]
   - Type 2: the link local IPv6 address (numbered bundle) using the
     format defined in [RFC3209]
   - Type 4: the link local identifier (unnumbered links and bundles)
     using the format defined in [RFC3477]
   - Type 64: the Maximum Reservable Bandwidth corresponding to this
     bundle (see [BUNDLE])
   - Type 65: the interface switching capability descriptor (see
     [GMPLS-RTG]) corresponding to this bundle (see also [BUNDLE]).

   Note: future revisions of this document may extend the above list.

   This object MAY also be used to exchange more than one bundled link
   capability. In this case, the following ordering MUST be followed:
   one identifier subobject (Type 1, 2 or 4) MUST be inserted before any
   capability subobject (Type 64 or 65) to which it refers.

6.3 Revised Message Formats

   The Notify message is enhanced (and referred thereby to as an
   unsolicited Notify message) to support Call establishment and


D.Papadimitriou et al. - Expires January 2006                       14
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


   teardown of Calls that operate independent of LSPs. See section 7 for
   a description of the procedures.

6.3.1 Notify Message

   The Notify message is modified in support of Call establishment by
   the optional addition of the LINK CAPABILTY object. Further, the
   SESSION ATTRIBUTE object is added to the <notify session> sequence to
   carry the long Call ID. The presence of the SESSION ATTIBUTE object
   MAY be used to distinguish a Notify message used for Call management.
   The <notify session list> MAY be used to setup simultaneously
   multiple Calls.

   The format of the Notify Message is as follows:

   <Notify message>  ::= <Common Header> [ <INTEGRITY> ]
                         [[ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]...]
                         [ <MESSAGE_ID> ]
                         <ERROR_SPEC>
                         <notify session list>

   <notify session list> ::= [ <notify session list> ] <notify session>

   <notify session>  ::= <SESSION> [ <ADMIN_STATUS> ]
                         [ <POLICY_DATA>...]
                         [ <LINK_CAPABILITY> ]
                         [ <SESSION_ATTRIBUTE> ]
                         [ <sender descriptor> | <flow descriptor> ]

   <sender descriptor> ::= see [RFC3473]

   <flow descriptor> ::= see [RFC3473]

6.4 ADMIN_STATUS Object

   Messages (such as Notifys, Paths, etc.) exchanged for Call control
   and management purposes carry a specific new bit (the Call Management
   or C bit) in the ADMIN STATUS object.

   The format and the contents of the ADMIN_STATUS object are both
   dictated by [RFC3473] in favor of [RFC3471]. The new "C" bit is added
   as shown below.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R|                        Reserved                     |C|T|A|D|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Reflect (R): 1 bit - see [RFC3471]
        Testing (T): 1 bit - see [RFC3471]
        Administratively down (A): 1 bit - see [RFC3471]
        Deletion in progress (D): 1 bit - see [RFC3471]

D.Papadimitriou et al. - Expires January 2006                       15
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005



        Call Management (C): 1 bit

            This bit is set when the message is being used to control
            and manage a Call.

   The procedures for the use of the C bit are described in section 7.

   Note that the use of the C bit may appear as redundant since Call
   setup can be distinguished by the presence of the SESSION ATTRIBUTE
   object in a Notify message or an non-zero short Call ID value in a
   Path message. However, in the case of lost messages and node restart,
   this further distinction is useful to distinguish Path messages that
   set up Calls from Path messages that belong to calls.

7. Procedures in Support of Calls and Connections

7.1 Call/Connection Setup Procedures

   This section describes the processing steps for call and connection
   setup.

   There are four cases considered:

   - A Call and Connection may be established simultaneously. That is,
     a Connection may be established and designated as belonging to a
     new Call. It is an implementation decision how the work a the
     ingress and egress points is split and whether the qualities of
     the Call are policed before, after or at the same time as those of
     the Connection. In the event that the establishment of either the
     Call or the Connection fails, an error is returned as described in
     Section 7.4.2 and neither is set up.

   - A Call can be set up on its own. That is, without any associated
     Connection. It is assumed that Connections will be added to the
     Call at a later time, but this is neither a requirement nor
     a constraint.

   - A Connection may be added to an existing Call. This may happen if
     the Call was set up without any associated Connections, or if a
     further Connection is added to a Call that already has one or more
     associated Connections.

   - A Connection may be established without any reference to a Call.
     This encompasses the previous LSP setup procedure.

   Note that a Call MAY NOT be imposed upon a Connection that is already
   established. To do so would require changing the short Call Id in the
   SESSION OBJECT of the existing LSPs and this would constitute a
   change in the Session Identifier. This is not allowed by existing
   protocol specifications.



D.Papadimitriou et al. - Expires January 2006                       16
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


   Call and Connection teardown procedures are described later in
   Section 7.7.

7.2 Independent Call Setup

   It is possible to set up a Call before, and independent of, LSP
   setup. A Call setup without LSPs MUST follow the procedure described
   in this section.

   Prior to the LSP establishment, Call setup MAY necessitate
   verification of the link status and link capability negotiation
   between the Call ingress node and the Call egress node. The procedure
   described below is applied only once for a Call and hence only once
   for the set of LSPs associated with a Call.

   The Notify message (see [RFC3473]) is used to signal the Call setup
   request and response. The new Call Management (C) bit in the
   ADMIN_STATUS object is used to indicate that this Notify is managing
   a Call. The Notify message is sent with source and destination
   IPv4/IPv6 address set to any of the routable ingress/egress node
   addresses respectively.

   At least one session MUST be listed in the <notify session list> of
   the Notify message. In order to allow for long identification of the
   Call the SESSION_ATTRIBUTE object is added as part of the <notify
   session list>. Note that the ERROR SPEC object is not relevant in
   Call setup and MUST carry the Error Code zero ("Confirmation") to
   indicate that there is no error.

   During Call setup, the ADMIN STATUS object is sent with the following
   bits set. Bits not listed MUST be set to zero.

   R - to cause the egress to respond
   C - to indicate that this message is managing a Call.

   The SESSION, SESSION ATTRIBUTE, SENDER_TEMPLATE, SENDER_TSPEC objects
   included in the <notify session> of the Notify message are built as
   follows:

   - The SESSION object includes as Tunnel_End_Point_Address any of the
     call terminating (egress) node's IPv4/IPv6 routable addresses. The
     Call_ID is set to a non-zero value unique within the context of
     the address pairing provided by the Tunnel_End_Point_Address and
     the Sender_Address from the SENDER TEMPLATE object (see below).
     Note that the Call_ID value of zero is reserved and MUST NOT be
     used during LSP-independent call establishment. The Tunnel_ID of
     the SESSION object is not relevant for this procedure and SHOULD
     be set to zero. The Extended_Tunnel_ID of the SESSION object is
     not relevant for this procedure and MAY be set to zero or to an
     address of the ingress node.

   - The SESSION ATTRIBUTE object contains priority flags. Currently no
     use of these flags is envisioned, however, future work may

D.Papadimitriou et al. - Expires January 2006                       17
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


     identify value is assigning priorities to Calls; accordingly the
     Priority fields MAY be set to non-zero values. None of the Flags
     in the SESSION ATTRIBUTE object are relevant to this process and
     this field SHOULD be set to zero. The Session Name field is used
     to carry the long Call Id as described in Section 6.

   - The SENDER_TEMPLATE object includes as Sender Address any of the
     call initiating (ingress) node's IPv4/IPv6 routable addresses. The
     LSP_ID is not relevant and SHOULD be set to zero.

   - The bandwidth value inserted in the SENDER_TSPEC and FLOWSPEC
     objects MUST be ignored upon receipt and SHOULD be set to zero
     when sent.

   Additionally, ingress/egress nodes that need to communicate their
   respective link local capabilities may include a LINK_CAPABILITY
   object in the Notify message.

   The receiver of a Notify message may identify whether it is part of
   Call management or reporting an error by the presence or absence of
   the SESSION ATTRIUBTE object in the <notify session list>. Full
   clarity, however, may be achieved by inspection of the new Call
   Management (C) bit in the ADMIN STATUS object.

   Note that the POLICY_DATA object may be included in the <notify
   session list> and may be used to identify requestor credentials,
   account numbers, limits, quotas, etc. This object is opaque to RSVP,
   which simply passes it to policy control when required.

   Message IDs MUST be used during independent Call setup.

7.2.1 Accepting Independent Call Setup

   A node that receives a Notify message carrying the ADMIN STATUS
   object with the R and C bits set is being requested to set up a Call.
   The receiver may perform authorization and policy according to local
   requirements.

   If the Call is acceptable, the receiver responds with a Notify
   message reflecting the information from the Call request with two
   exceptions.

   - The responder removes any LINK CAPABLITY object that was received
     and MAY insert a LINK CAPABILITY object that describes its own
     access link.

   - The ADMIN STATUS object is sent with only the C bit set. All other
     bits MUST be set to zero.

   The responder MAY use the Message ID object to ensure reliable
   delivery of the response. If no Message ID Acknowledgement is
   received after the configured number of retries, the responder should


D.Papadimitriou et al. - Expires January 2006                       18
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


   continue to assume that the Call was successfully established. Call
   liveliness procedures are covered in section 7.8.

7.2.2 Rejecting Independent Call Setup

   Call setup may fail or be rejected.

   If the Notify message can not be delivered, no Message ID
   acknowledgement will be received by the sender. In the event that the
   sender has retransmitted the Notify message a configurable number of
   times without receiving a Message ID Acknowledgement (as described in
   [RFC3473]), the initiator SHOULD declare the Call failed and SHOULD
   send a Call teardown request (see section 7.7).

   It is also possible that a Message ID Acknowledgement is received but
   no Call response Notify message is received. In this case, the
   initiator MAY re-send the Call setup request a configurable number of
   times (see Section 7.8) before declaring the Call has failed. At this
   point the initiator MUST send a Call teardown request (see Section
   7.7).

   If the Notify message cannot be parsed or is in error it MAY be
   responded to with a Notify message carrying the error code 13
   ("Unknown object class") or 14 ("Unknown object C-Type").

   The Call setup may be rejected by the receiver because of security,
   authorization or policy reasons. Suitable error codes already exist
   and can be used in the ERROR SPEC object included in the Notify
   message sent in response.

   Error response Notify messages SHOULD also use the Message ID object
   to achieve reliable delivery. No action should be taken on the
   failure to receive a Message ID Acknowledgement after the configured
   number of retries.

7.3 Adding a Connections to a Call

   Once a Call has been established, LSPs can be added to the Call.
   Since the short Call ID is part of the SESSION Object, any LSP that
   has the same Call ID value in the SESSION Object belongs to the same
   Call. There will be no confusion between LSPs that are associated
   with a Call and those which are not since the Call ID value MUST be
   equal to zero for LSPs which are not associated with a Call.

   LSPs for different Calls can be distinguished because the Call ID is
   unique within the context of the source address (in the SENDER
   TEMPLATE object) and the destination address (in the SESSION object).

   Ingress and egress nodes may group together LSPs associated with the
   same call and process them as a group according to implementation
   requirements. Transit nodes need not be aware of the association of
   multiple LSPs with the same Call.


D.Papadimitriou et al. - Expires January 2006                       19
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


   The ingress node MAY choose to set the "Session Name" of an LSP to
   match the long Call ID of the associated Call and the "Session Name"
   MAY still be used to distinguish between virtually concatenated LSPs
   belonging to the same Call. Thus, there is not necessarily a one-to-
   one mapping between the "Session Name" of an LSP and the short
   Call_ID.

   The C bit of the ADMIN STATUS object MUST NOT be set on LSP messages.

7.3.1 Adding a Reverse Direction LSP to a Call

   Note that once a Call has been established it is symmetric. That is,
   either end of the Call may add LSPs to the Call.

   Special care is needed when managing LSPs in the reverse direction
   since the addresses in the SESSION and SENDER TEMPLATE are reversed.
   However, since the short Call ID is unique in the context of a given
   ingress-egress address pair it may safely be used to associate the
   LSP with the Call.

7.4 Simultaneous Call/Connection Setup

   It is not always necessary to establish a Call before adding
   Connections to the Call. Where the features made available by
   independent Call setup are not required, a simplification can be made
   by establish a Call at the same time as the first Connection
   associated to the Call.

   Simultaneous Call and LSP setup requires the usage of Call
   identification and an indication that a Call is being managed. No
   other protocol mechanisms beyond those described in [RFC3473] are
   needed. Normal RSVP-TE GMPLS processing takes place.

   The Path message used to simultaneously set up the Call and LSP MUST
   carry the ADMIN STATUS object with the R and C bits set. Other bits
   may be set or cleared according to the requirements of LSP setup. The
   D bit MUST NOT be set.

   The Path message MUST also carry the long Call ID in the Session Name
   field of the SESSION ATTRIBUTE object as described above. This field
   is not available to contain a Session Name distinct from the Call ID.

   A non-zero short Call ID MUST be placed in the new Call ID field of
   the SESSION object as described above. The reserved value of zero is
   used when the LSP is being set up with no association to a Call.

7.4.1 Accepting Simultaneous Call/Connection Setup

   A Path message that requests simultaneous Call and Connection setup
   is subject to local authorization and policy procedures applicable to
   Call establishment in addition to the standard procedures associated
   with LSP setup described in [RFC3473].


D.Papadimitriou et al. - Expires January 2006                       20
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


   If the Call and LSP setup is to be accepted, a Resv message is
   returned. The Resv message MUST carry the ADMIN STATUS object with
   the R bit clear and the C bit set. Other bits may be set or cleared
   according to the requirements of LSP setup. The D bit MUST NOT be
   set.

   The Call ID MUST be reflected in the SESSION object.

7.4.2 Rejecting Simultaneous Call/Connection Setup

   The Path message that is sent to set up a Call and Connection
   simultaneously may fail or be rejected.

   Failures may include all those reasons described in [RFC3473].
   Additionally, policy and authorization reasons specifically
   associated with Call setup may cause the Path message to be rejected.

   The PathErr message is issued to signal such failures and no new
   error codes are required. It is RECOMMENDED that the procedures for
   PathErr with state removal described in [RFC3473] is used during Call
   setup failure processing.

7.5 Call-Free Connection Setup

   It continues to be possible to set up LSPs as per [RFC3473] without
   associating them with a Call. If the short Call ID in the SESSION
   Object is set to zero, there is no associated Call and the Session
   Name field in the SESSION ATTRIBUTE object SHOULD be interpreted
   simply as the name of the session (see [RFC3209]).

   The new C bit in the ADMIN STATUS object SHOULD be set to zero in
   such messages and MUST be ignored if the Call ID is zero.

7.6 Call Collision

   Since Calls are symmetrical, it is possible that both ends of a call
   will attempt to establish a Call with the same long Call ID at the
   same time. This is only an issue if the source and destination
   address pair matches. This situation can be avoided by applying some
   rules to the contents of the long Call ID, but that is outside the
   scope of this document.

   If a node that has sent a Call setup request and has not yet received
   a response, itself receives a Call setup request with the same long
   Call ID and matching source/destination addresses it should process
   as follows.

   - If its source address is numerically greater than the remote
     source address, it MUST discard the received message and continue
     to wait for a response to its setup request.

   - If its source address is numerically smaller than the remote
     source address, it MUST discard state associated with the Call

D.Papadimitriou et al. - Expires January 2006                       21
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


     setup that it initiated, and MUST respond to the received Call
     setup.

   In the second case, special processing is necessary if simultaneous
   Call and Connection establishment was being used. Firstly, the node
   that is discarding the Call that it initiated MUST send a PathTear
   message to remove state from transit nodes. Secondly, this node may
   want to hold onto the Connection request and establish an LSP once
   the Call is in place since only the Call that it was trying to
   establish has been set up by the destination - the Connection may
   still be required.

   A further possibility for contention arises when Call IDs are
   assigned by a pair of nodes for two distinct Calls that are set up
   simultaneously. In this event a node receives a Call setup request
   carrying a short Call ID that matches one that it previously sent for
   the same address pair. The following processing MUST be followed.

   - If the receiver's source address is numerically greater than the
     remote source address, the receiver returns an error (Notify
     message or PathErr message as appropriate) with the new Error Code
     "Call Management" (TBD) and the new Error Value "Call ID
     Contention" (TBD).

   - If the receiver's source address is numerically less than the
     remote source address, the receiver accepts and processes the Call
     request. It will receive an error message sent as described above,
     and at that point it selects a new short Call ID and re-sends the
     Call setup request.

   Note: these procedures apply for any combination of independent and
   simultaneous call establishment.

7.7 Call/Connection Teardown

   As with Call/Connection setup, there are several cases to consider.

   - Removal of a Connection from a Call
   - Removal of the last Connection from a Call
   - Teardown of an "empty" Call

   The case of tearing down an LSP that is not associated with a Call
   does not need to be examined as it follows exactly the procedures
   described in [RFC3473].

7.7.1 Removal of a Connection from a Call

   An LSP that is associated with a Call may be deleted using the
   standard procedures described in [RFC3743]. No special procedures are
   required.

   Note that it is not possible to remove an LSP from a Call without
   deleting the LSP. It is not valid to change the short Call ID from

D.Papadimitriou et al. - Expires January 2006                       22
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


   non-zero to zero since this involves a change to the SESSION object,
   which is not allowed.

7.7.2 Removal of the Last Connection from a Call

   When the last LSP associated with a Call is deleted the question
   arises as to what happens to the Call. Since a Call may exist
   independently of Connections, it is not always acceptable to say that
   the removal of the last LSP from a Call removes the Call.

   If the Call was set up using independent Call setup (that is, using a
   Notify message) the removal of the last LSP does not remove the Call
   and the procedures described in the next section MUST be used to
   delete the Call.

   If the Call was set up using simultaneous Call/Connection
   establishment, the removal of the last LSP does remove the Call and
   the Call ID becomes invalid.

7.7.3 Teardown of an "Empty" Call

   When all LSPs have been removed from a Call that was set up
   independent of Connections, the Call may be torn down or left for use
   by future LSPs.

   Deletion of such Calls is achieved by sending a Notify message just
   as for Call setup, but the ADMIN STATUS object carries the R, D and C
   bits on the teardown request and the D and C bits on the teardown
   response. Other bits MUST be set to zero.

   When a Notify message is sent for deleting a call and the initiator
   does not receive the corresponding reflected Notify message (or
   possibly even the Message ID Ack), the initiator MAY retry the
   deletion request using the same retry procedures as used during Call
   establishment. If no response is received after full retry, the node
   deleting the Call MAY declare the Call deleted, but under such
   circumstances the node SHOULD avoid re-using the long or short Call
   IDs for at least the five times the Notify refresh period.

7.7.4 Teardown of a Call with Existing Connections

   If a Notify request with the D bit of the ADMIN STATUS object set is
   received for a Call for which LSPs still exist, the request MUST be
   rejected with the Error Code "Call Management" (TBD) and Error Value
   "Connection Still Exists" (TBD).

7.7.5 Teardown of a Call from the Egress

   Since Calls are symmetric they may be torn down from the ingress or
   egress.

   If the Call was established using simultaneous Call/Connection setup
   the removal of the last LSP deletes the Call. This, regardless of

D.Papadimitriou et al. - Expires January 2006                       23
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


   whether the LSP is torn down by using a PathTear message (for an
   egress-initiated LSP) or by using a PathErr message with the
   Path_State_Removed flag set (for an ingress-initiated LSP).

   If the Call was established using independent Call/Connection setup
   and the Call is "empty" it may be deleted by the egress sending a
   Notify message just as described above.

   Note that there is still a possibility that both ends of a Call
   initiate a simultaneous Call deletion. In this case, the Notify
   message acting as teardown request is interpreted by its recipient as
   a teardown response. Since the Notify messages carry the R bit in the
   ADMIN STATUS object, they are responded to anyway. If a teardown
   request Notify message is received for an unknown Call ID it is,
   nevertheless, responded to in the affirmative.

7.8 Control Plane Survivability

   Delivery of Notify messages is secured using message ID
   acknowledgements as described in previous sections.

   Notify messages provide end-to-end communication that does not rely
   on constant paths through the network but are routed according to IGP
   routing information. No consideration is, therefore, required for
   network resilience (for example, make-before-break, protection, fast
   re-route), although end-to-end resilience is of interest for node
   restart and completely disjoint networks.

   Periodic Notify messages SHOULD be sent by the initiator and
   terminator of the Call to keep the Call alive and to handle ingress
   or egress node restart. The time period for these retransmissions is
   a local matter, but it is RECOMMENDED that this period should be
   twice the refresh period of the LSPs associated with the Call. The
   Notify messages are identical to those sent as if establishing the
   Call for the first time, except for the LINK CAPABILITY object, which
   may have changed since the Call was first established, due to, e.g.,
   the establishment of connections, link failures, and the addition of
   new component links. The current link information is useful for the
   establishment of subsequent connections. A node that receives a
   refresh Notify message MUST respond with a Notify response. A node
   that receives a refresh Notify message (response or request) MAY
   reset its timer - thus, in normal processing, Notify refreshes
   involve a single exchange once per time period.

   A node that is unsure of the status of a Call MAY immediately send a
   Notify message as if establishing the Call for the first time.

   Failure to receive a refresh Notify request has no specific meaning.
   If it receives no response to a refresh Notify request (including no
   Message ID Acknowledgement) a node MAY assume that the remote node is
   unreachable or unavailable. It is a local policy matter whether this
   causes the local node to teardown associated LSPs and delete the
   Call.

D.Papadimitriou et al. - Expires January 2006                       24
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005



   In the event that an edge node restarts without preserved state, it
   MAY relearn LSP state from adjacent nodes and Call state from remote
   nodes. If a Path or Resv message is received with a non-zero Call ID
   but without the C bit in the ADMIN STATUS, and for a Call ID that is
   not recognized, the receiver is RECOMMENDED to assume that the Call
   establishment is delayed and ignore the received message. If the Call
   setup never materializes the failure by the restarting node to
   refresh state will cause the LSPs to be torn down. Optionally, the
   receiver of such an LSP message for an unknown Call ID may return an
   error (PathErr or ResvErr) with the error code "Call Management"
   (TBD) and Error Value "Unknown Call ID" (TBD).

8. Applicability of Call and Connection Procedures

   This section considers the applicability of the different Call
   establishment procedures at the NNI and UNI reference points. This
   section is informative and is not intended to prescribe or prevent
   other options.

8.1 Network-initiated Calls

   Both independent and simultaneous Call/Connection setups are
   applicable.

   Since the link properties and other traffic-engineering attributes
   are likely known through the IGP, the LINK CAPABILITY object is not
   usually required.

   In multi-area networks, possibly, access link properties and other
   traffic-engineering attributes are not known since the areas do not
   leak this sort of information. In this case, the independent Call
   setup mechanism may be preferred to allow the inclusion of the LINK
   CAPABILITY object.

8.2 User-initiated Calls

   Both independent and simultaneous Call/Connection setups are
   applicable.

   It is possible that the access link properties and other traffic-
   engineering attributes are not shared across the core network. In
   this case, the independent Call setup mechanism may be preferred to
   allow the inclusion of the LINK CAPABILITY object.

   Further, the first node in the network may be responsible for
   managing the Call. In this case, the Notify message that is used to
   set up the Call is addressed to the first node of the core network.
   Moreover, neither the long Call ID nor the short Call ID is supplied
   (the Session Name Length is set to zero and the Call ID value is set
   to zero). The Notify message is passed to the first network node
   which is responsible for generating the long and short Call IDs
   before dispatching the message to the remote Call end point (which is

D.Papadimitriou et al. - Expires January 2006                       25
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


   known from the SESSION object). Similarly, the first network node may
   be responsible for generating the long and short Call IDs for
   inclusion in Path messages that have the C bit set in the ADMIN
   STATUS object.

   Further, when used in an overlay context, the first core node is
   allowed (see [GMPLS-OVERLAY]) to replace the Session Name assigned by
   the ingress node and passed in the Path message. In the case of Call
   management, the first network node MUST in addition 1) be aware that
   the name it inserts MUST be a long Call ID and 2) replace the long
   Call ID when it returns the Resv message to the ingress node.

8.3 External Call Managers

   Third party Call management agents may be used to apply policy and
   authorization at a point that is neither the initiator nor terminator
   of the Call. The previous example is a particular case of this, but
   the process and procedures are identical.

8.3.1 Call Segments

   Call segments exist between a set of default and configured External
   Call Managers along a path between the ingress and egress nodes, and
   use the protocols described in this document.

   The techniques that are used by a given service provider to identify
   which External Call Managers within its network should process a
   given call are beyond the scope of this document.

   For independent call setup, an External Call manager uses normal IP
   routing to route the Notify message to the next External Call
   Manager. For simultaneous call/connection setup, an External Call
   Manager expands the EXPLICIT_ROUTE Object to route the Path message
   to the next External Call Manager.

9. Non-support of Call ID

   It is important that the procedures described above operate as
   seamlessly as possible with legacy nodes that do not support the
   extensions described.

   Clearly there is no need to consider the case where the Call
   initiator does not support Call setup initiation.

9.1 Non-Support by External Call Managers

   It is unlikely that a Call initiator will be configured to send Call
   establishment Notify requests to an external Call manager including
   the first network node, if that node does not support Call setup.

   A node that receives an unexpected Call setup request will fall into
   one of the following categories.


D.Papadimitriou et al. - Expires January 2006                       26
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


   - Node does not support RSVP. The message will fail to be delivered
     or responded. No Message ID Acknowledgement will be sent. The
     initiator will retry and then give up.

   - Node supports RSVP or RSVP-TE but not GMPLS. The message will be
     delivered but not understood. It will be discarded. No Message ID
     Acknowledgement will be sent. The initiator will retry and then
     give up.

   - Node supports GMPLS but not Call management. The message will be
     delivered, but parsing will fail because of the presence of the
     SESSION ATTRIBUTE object. A Message ID Acknowledgement may be sent
     before the parse fails. When the parse fails the Notify message
     may be discarded in which case the initiator will retry and then
     give up, alternatively a parse error may be generated and returned
     in a Notify message which will indicate to the initiator that Call
     management is not set up.

9.2 Non-Support by Transit Node

   Transit nodes SHOULD not examine Notify messages that are not
   addressed to them. However, they will see short Call IDs in all LSPs
   associated with Calls. Further, they will see the C bit in the ADMIN
   STATUS object of Path and Resv messages that are used to establish
   Calls.

   Previous specifications state that these fields SHOULD be ignored on
   receipt and MUST be transmitted as zero. This is interpreted by some
   implementations as meaning that the fields should be zeroed before
   the objects are forwarded. If this happens, LSP setup (and so
   possibly Call setup if simultaneous establishment is used) will not
   be possible. If either of the fields is zeroed either on the Path or
   the Resv message, the Resv will reach the initiator with the field
   set to zero - this is indication to the initiator that some node in
   the network is preventing Call management. Use of Explicit Routes may
   help to mitigate this issue by avoiding such nodes. The use of
   independent Call setup may also help since it removes the need for
   the C bit in the Path and Resv messages. Ultimately, however, it may
   be necessary to upgrade the offending nodes to handle these protocol
   extensions.

9.3 Non-Support by Egress Node

   It is unlikely that an attempt will be made to set up a Call to
   remote node that does not support Calls.

   If the egress node does not support Call management through the
   Notify message it will react (as described in Section 9.1) in the
   same way as an external Call manager.

   If the egress node does not support the use of the C bit in the ADMIN
   STATUS object or the Call ID in the SESSION object, it MAY respond


D.Papadimitriou et al. - Expires January 2006                       27
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


   with the fields zeroed in which case the initiator will know that the
   Call setup has failed.

   On the other hand, it is possible that the egress will respond
   copying the fields from the Path message without understanding or
   acting on the fields. In this case the initiator will believe that
   the Call has been set up when it has not. This occurrence can be
   prevented using the independent Call setup procedures, but is, in any
   case, detected when a Notify message is sent to keep the Call alive.

10. Security Considerations

   Please refer to each of the referenced documents for a description of
   the security considerations applicable to the features that they
   provide.

10.1 Call and Connection Security Considerations

   Call setup is vulnerable to attacks both of spoofing and denial of
   service. Since Call setup uses either Path messages or Notify
   messages, the process can be protected by the measures applicable to
   securing those messages as described in [RFC3471], [RFC3209] and
   [RFC2205].

   Note, additionally, that the process of Call establishment
   independent of LSP setup may be used to apply an extra level of
   authentication and policy to hop-by-hop LSP setup. It may be possible
   to protect the Call setup exchange using end-to-end security
   mechanisms such as those provided by Insect (see [RFC2402] and
   [RFC2406]).

11. IANA Considerations

   A new RSVP object is introduced:

   o  LINK CAPABILITY object

      Class-Num = TBA (form 10bbbbbb)

      The Class Number is selected so that nodes not recognizing
      this object drop it silently. That is, the top bit is set
      and the next bit is cleared.

      C-Type = 1 (TE Link Capabilities)

   New RSVP Error Codes and Error Values are introduced

   o  Error Codes:

      - Call Management (value TBA)

   o  Error Values:


D.Papadimitriou et al. - Expires January 2006                       28
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


      - Call Management/Call ID Contention      (value TBA)
      - Call Management/Connections still Exist (value TBA)
      - Call Management/Unknown Call ID         (value TBA)

12. Acknowledgements

   The authors would like to thank George Swallow, Yakov Rekhter, Lou
   Berger, Jerry Ash and Kireeti Kompella for their very useful input
   and comments to this document.

13. References

13.1 Normative References

   [ASON-REQ]      D.Papadimitriou, et al., "Requirements for
                   Generalized MPLS (GMPLS) Usage and Extensions for
                   Automatically Switched Optical Network (ASON)," Work
                   in progress, Oct'04.

   [BUNDLE]        K.Kompella, Y.Rekhter and L.Berger, "Link Bundling
                   in MPLS Traffic Engineering," Work in Progress.

   [GMPLS-CRANK]   A.Farrel (Editor) et al., "Crankback Routing
                   Extensions for MPLS Signaling," Work in progress,
                   Oct'04.

   [GMPLS-FUNCT]   J.P.Lang and B.Rajagopalan (Editors) et al.,
                   "Generalized MPLS Recovery Functional
                   Specification," Work in Progress, Oct'04.

   [GMPLS-OVERLAY] G.Swallow et al., "GMPLS RSVP Support for the
                   Overlay Model," Work in Progress, Oct'04.

   [GMPLS-ROUTING] K.Kompella and Y.Rekhter (Editors) et al., "Routing
                   Extensions in Support of Generalized MPLS," Work in
                   Progress, Oct'03.

   [LMP]           J.P.Lang (Editor) et al. "Link Management Protocol
                   (LMP) - Version 1," Work in progress, Oct'03.

   [RFC2026]       S.Bradner, "The Internet Standards Process --
                   Revision 3," BCP 9, RFC 2026, Oct'96.

   [RFC2119]       S.Bradner, "Key words for use in RFCs to Indicate
                   Requirement Levels," BCP 14, RFC 2119, Mar'97.

   [RFC2205]       R.Braden et al., "Resource ReSerVation Protocol
                   (RSVP)- Version 1 Functional Specification,"
                   RFC 2205, Sep'97

   [RFC2402]       S.Kent and R.Atkinson, "IP Authentication Header,"
                   RFC 2402, Nov'98.


D.Papadimitriou et al. - Expires January 2006                       29
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


   [RFC2406]       S.Kent and R.Atkinson, "IP Encapsulating Payload
                   (ESP)," RFC 2406, Nov'98.

   [RFC3209]       D.Awduche et al., "RSVP-TE: Extensions to RSVP for
                   LSP Tunnels," RFC 3209, Dec'01.

   [RFC3471]       L.Berger (Editor) et al., "Generalized MPLS -
                   Signaling Functional Description," RFC 3471, Jan'03.

   [RFC3473]       L.Berger (Editor) et al., "Generalized MPLS
                   Signaling - RSVP-TE Extensions," RFC 3473, Jan'03.

   [RFC3477]       K.Kompella and Y.Rekhter, "Signalling Unnumbered
                   Links in Resource ReSerVation Protocol - Traffic
                   Engineering (RSVP-TE)," RFC 3477, Jan'03.

   [RFC3667]       S.Bradner, "IETF Rights in Contributions", BCP 78,
                   RFC 3667, February 2004.

   [RFC3668]       S.Bradner, Ed., "Intellectual Property Rights in IETF
                   Technology", BCP 79, RFC 3668, February 2004.

   [RFC3945]       E.Mannie, Ed., "Generalized Multi-Protocol Label
                   Switching (GMPLS) Architecture", RFC 3945, October
                   2004.

   [RSVP-CHANGE]   K.Kompella and J.P.Lang, "Procedures for Modifying
                   RSVP," Work in Progress, draft-kompella-rsvp-change-
                   01.txt, Jun'03.

13.2 Informative References

   [RFC3474]       Z.Lin (Editor), " Documentation of IANA assignments
                   for Generalized MultiProtocol Label Switching
                   (GMPLS) Resource Reservation Protocol - Traffic
                   Engineering (RSVP-TE) Usage and Extensions for
                   Automatically Switched Optical Network (ASON)," RFC
                   3474, Mar'03.

   [RFC3476]       B.Rajagopalan (Editor), "Documentation of IANA
                   Assignments for Label Distribution Protocol
                   (LDP), Resource ReSerVation Protocol (RSVP), and
                   Resource ReSerVation Protocol-Traffic Engineering
                   (RSVP-TE) Extensions for Optical UNI Signaling," RFC
                   3476, Mar'03.

   For information on the availability of the following documents,
   please see http://www.itu.int.

   [G.7713]        ITU-T, "Distributed Call and Connection Management,"
                   Recommendation G.7713/Y.1304, Nov'01.



D.Papadimitriou et al. - Expires January 2006                       30
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


   [G.7713.2]      ITU-T, "DCM Signalling Mechanisms Using GMPLS RSVP-
                   TE," Recommendation G.7713.2, Jan'03.

   [G.8080]        ITU-T, "Architecture for the Automatically Switched
                   Optical Network (ASON)," Recommendation G.8080/
                   Y.1304, Nov'01 (and Revision, Jan'03).

14. Author's Addresses

   Dimitri Papadimitriou (Alcatel)
   Fr. Wellesplein 1,
   B-2018 Antwerpen, Belgium
   Phone: +32 3 240-8491
   EMail: dimitri.papadimitriou@alcatel.be

   John Drake
   Boeing Satellite Systems
   2300 East Imperial Highway
   El Segundo, CA 90245
   EMail: John.E.Drake2@boeing.com

   Adrian Farrel
   Old Dog Consulting
   Phone: +44 (0) 1978 860944
   EMail: adrian@olddog.co.uk

   Deborah Brungard (AT&T)
   Rm. D1-3C22 - 200 S. Laurel Ave.
   Middletown, NJ 07748, USA
   EMail: dbrungard@att.com

   Zafar Ali (Cisco)
   100 South Main St. #200
   Ann Arbor, MI 48104, USA
   EMail: zali@cisco.com

   Arthi Ayyangar (Juniper)
   1194 N.Mathilda Ave
   Sunnyvale, CA 94089, USA
   EMail: arthi@juniper.net

   Don Fedyk (Nortel Networks)
   600 Technology Park Drive
   Billerica, MA, 01821, USA
   Email: dwfedyk@nortelnetworks.com








D.Papadimitriou et al. - Expires January 2006                       31
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005





Appendix 1: Analysis of G.7713.2 against GMPLS RSVP-TE Signaling
Requirements in support of ASON

   Informational RFC [RFC3474] (and [RFC3476]) documents the code points
   for the signaling extensions defined in [G.7713.2] to meet the
   requirements of ASON Distributed Call and Connection Management (DCM)
   as specified in [G.7713].

   While [G.7713.2] make use of GMPLS RSVP-TE signaling, there are key
   differences from the problem statement in [ASON-REQ] and the solution
   it provides. These differences result from the development of a
   fuller and clearer set of requirements in [G.8080] after the time
   that [G.7713.2] was published and [ASON-REQ] considerations for
   compatibility aspects with GMPLS [RFC3473]. These differences lead to
   a substantially different protocol solution and implementation.

   This appendix analyzes the rationale and the relevance of the
   informational IANA code-point assignments RFCs [RFC3474] and
   [RFC3476] against the ASON requirements identified in [ASON-REQ]. The
   latter details the requirements to be covered by the extensions to
   the GMPLS signaling protocols (see [RFC3471] and [RFC3473]) to
   support the capabilities of an ASON network. The following are
   expected from the GMPLS protocol suite to realize the needed ASON
   functionality:
    o soft permanent connection capability
    o call and connection separation
    o call segments
    o extended restart capabilities during control plane failures
    o extended label usage
    o crankback capability

1. Support for UNI and E-NNI Signaling Session

   In GMPLS (see [RFC3473] and related), a connection is identified with
   a GMPLS tunnel. A tunnel is generally identified with a single LSP
   but may be supported by multiple LSPs.

   LSP tunnels are identified by a combination of the SESSION and
   SENDER_TEMPLATE objects. The relevant fields are as follows.

   IPv4 (or IPv6) tunnel end point address

        IPv4 (or IPv6) address of the egress node for the tunnel.

   Tunnel ID

        A 16-bit identifier used in the SESSION that remains constant
        over the life of the tunnel.

   Extended Tunnel ID

D.Papadimitriou et al. - Expires January 2006                       32
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005



        A 32-bit (IPv4) or 128-bit (IPv6) identifier used in the SESSION
        that remains constant over the life of the tunnel. Normally set
        to all zeros. Ingress nodes that wish to narrow the scope of a
        SESSION to the ingress-egress pair may place their IP address
        here as a globally unique identifier.

   IPv4 (or IPv6) tunnel sender address

        IPv4 (or IPv6) address for a sender node

   LSP ID

        A 16-bit identifier used in the SENDER_TEMPLATE and the
        FILTER_SPEC that can be changed to allow a sender to share
        resources with itself.

   The first three of these are in the SESSION object and are the basic
   identification of the tunnel. The "Extended Tunnel ID" MAY be set to
   an IP address of the head-end LSR allowing the scope of the SESSION
   to be narrowed to only LSPs sent by that node. The last two are in
   the SENDER_TEMPLATE. Multiple LSPs may belong to the same tunnel (and
   thus SESSION) and in this case they are uniquely identified by their
   LSP IDs.

   In contrast, [G.7713.2] defines an E-NNI IPv4/IPv6 SESSION object and
   an UNI IPv4/IPv6 SESSION object. It mandates the use of these objects
   to support the E-NNI (UNI, respectively) signaling session when IPv4
   and IPv6 addressing is used. The "Tunnel End-point Address" field
   contains the IPv4 or IPv6 address of the downstream controller. In
   addition, [G.7713.2] mandates that the "Extended Tunnel ID" field to
   be set to the IPv4 or IPv6 of the upstream controller. It also
   mandates that the tunnel sender address field of the SENDER_TEMPLATE
   be set to the IPv4 or the IPv6 address of the upstream controller.

   Thus, these RFCs define a point-to-point signaling interface allowing
   for LSP tunnel provisioning between adjacent controllers only. This
   approach mandates the introduction of an additional object and sub-
   objects for connection identification purposes (see [G.7713.2]): the
   GENERALIZED_UNI object and its connection end-point address sub-
   objects (IPv4/IPv6/NSAP) referred to as "TNA or Transport Network
   Address" as defined by the [OIF-UNI] implementation agreement.

   The situation is summarized in the following table, using the
   following example and a connection set from node A to Z:

      UNI                E-NNI              E-NNI                UNI
   A ----- B -- ... -- I ----- J -- .. -- M ----- N -- ... -- Y ----- Z

   At node I, the GMPLS compliant [RFC3473] Path message would include
   the following information in the IP header, the SESSION and
   SENDER_TEMPLATE objects:


D.Papadimitriou et al. - Expires January 2006                       33
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


   Source IP address (Header):  Node I IP Controller Address
   Dest. IP address (Header):   Node J IP Controller Address
   Tunnel End-point Address:    Routable Node Z IP Address
   Tunnel ID:                   16 bit (selected by the sender)
   Extended Tunnel ID:          optionally set to Node A IP Address
   Tunnel Sender Address:       Routable Node A IP Address
   LSP ID:                      16 bit (selected by the sender)

   At node I, the [G.7713.2] Path message would include the following:

   Source IP address (Header):  Node I IP Controller Address
   Dest. IP address (Header):   Node J IP Controller Address
   Tunnel End-point Address:    Node J IP Controller Address
   Tunnel ID:                   16 bit (selected by the sender)
   Extended Tunnel ID:          Node I IP Controller Address
   Tunnel Sender Address:       Node I IP Controller Address
   LSP ID:                      16 bit (selected by the sender)
   GENERALIZED_UNI object:
   - Source Address (Connection): End-point A Address (IPv4/IPv6/NSAP)
   - Dest. Address (Connection):  End-point Z Address (IPv4/IPv6/NSAP)

   The same observation would apply at node M, by replacing I by M and J
   by N.

   The following can be thus deduced from the above example:

   1. For a given connection, the [G.7713.2] point-to-point signaling
      interface leads to a sequence of at least N different
      identifications of the same connection when crossing N
      signaling interfaces (due to the setup and maintenance of N
      distinct LSP tunnels).

   2. The information included in the RSVP message header and in the
      SESSION/SENDER_TEMPLATE objects, is redundant in [G.7713.2].

   3. [G.7713.2] allows only for single-hop LSP tunnels and mandates
      the processing of a new object, i.e. the GENERALIZED_UNI object,
      for the definition of the source and destination connection end-
      point addresses (A and Z in the above example).

   4. The processing of the signaling Path message, in particular, the
      EXPLICIT ROUTE object (ERO), mandates the processing of the
      GENERALIZED_UNI object at E-NNI reference points and at UNI
      reference points, for the connection end-point addresses (A and
      Z, in the above example).

   5. Connection end-point addresses A and Z are allowed by [G.7713.2]
      to be from different address spaces (for instance, IPv4 source
      and IPv6 destination or an IPv4 source and NSAP destination).
      Address resolution, management of addresses, e.g., for
      uniqueness, and impact evaluation on processing performance, are
      not provided in these RFCs (considered out of scope).


D.Papadimitriou et al. - Expires January 2006                       34
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


      Note: the [ASON-REQ] addressing model of supporting only IP
      addressing is aligned with ITU-T G.7713.1 (PNNI) which only uses
      NSAP addresses, multiple address families are not supported.

   6. [G.7713.2] defines an incompatible and redundant addressing
      mechanism with [RFC3473] to support IPv4, IPv6, and NSAP
      addresses. [RFC3473] is part of a GMPLS protocol suite based on
      use of IPv4 and IPv6 addresses. The use of NSAP addresses with
      [RFC3473] is supported by established procedures defined in
      [RFC1884] "IPv6 Addressing Architecture", and only requiring
      support by border entities, e.g., DNS. Any other support for
      NSAP addressing is redundant with IETF supported procedures.
      [G.7713.2] provides no guidance on the operational aspects
      resulting from this modified procedure which uses a non-standard
      object, the GENERALIZED_UNI object, to support. Use of the
      GENERALIZED_UNI object requires every entity to support multi-
      address family resolution, e.g., for ERO processing, and in the
      case of multi-region path setup. Requiring multi-address family
      resolution at all entities severely impacts performance, scaling,
      and introduces unnecessary complexity for operations. This
      limitation is well recognized, e.g. [G.7713.2] use in demos has
      been limited to only IPv4 prefixes with pre-configured mappings.

   Conclusion:

   1) The solution proposed by [G.7713.2] is not backward compatible
   with [RFC3473]. A GMPLS-compliant node [RFC3473] is not interoperable
   with a [G.7713.2] node. Also, the "RSVP paradigm" is broken because
   the solution requires that all the UNI reference points (A, B and Y,
   Z, in the above example) and the E-NNI reference points (I, J and M,
   N, in the above example) support the GENERALIZED_UNI object.
   Additionally, the management of the network requires maintaining
   multiple LSP tunnels per single connection, with no end-to-end view
   provided for expedient fault notification or recovery operations.

   2) The solution proposed by [G.7713.2] also introduces processing
   overhead for address resolution that during time critical operations
   (such as recovery) will severely impact performance and scalability.
   Whereas the ITU-T G.7713.1 (PNNI) and [ASON-REQ] by using a single
   address family (with address mapping provided at edge nodes if
   needed) supports a scalable model for inter-domain interworking
   applications.

2. Support for Soft Permanent Connections (SPC)

   A Soft Permanent Connection (SPC) is defined as a permanent
   connection at the network edges and as a switched connection within
   the network.

   [G.7713.2] mandates the use of the GENERALIZED_UNI subobjects (End-
   point Connection Address and SPC_LABEL) to support SPC capability.
   Thus, in addition to suffering from the problem described in Section
   4, it mandates the processing of an object where it should never

D.Papadimitriou et al. - Expires January 2006                       35
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


   occur. This is because SPCs do not assume the existence of a UNI
   signaling interface between the source and the destination user-to-
   network interface. Note also that the SPC_LABEL as defined in
   [G.7713.2] does not comply with the generalized label C-Type
   definition of [RFC3473] meaning that an implementation adhering to
   [RFC3473] cannot be the "soft" side of the connection.

   This requires the mandatory usage of dedicated connection end-point
   addresses by the ingress and egress nodes for SPC capability support.
   The existing RECORD_ROUTE object and its capabilities get corrupted
   by the use of the dedicated end-point address subobjects falling
   outside of the corresponding EXPLICIT ROUTE object.

   SPC support is already provided by [RFC3473] using Explicit Label
   Control and its application to the overlay model in [GMPLS-OVERLAY].
   Therefore, [G.7713.2] defines a new method for an existing capability
   of GMPLS signaling.

3. Call/Connection Separation

   The call concept for optical networks is defined in [G.8080]. It is
   used to deliver the following capabilities:
   - Verification and identification of the call initiator (prior to
     LSP setup) including negotiation between call ingress/egress nodes
   - Support of multiple connections can be associated with a single
     call.
   - Facilitate control plane operations by allowing operational status
     change of the associated LSP.

   A call is an agreement between end-points (possibly in cooperation
   with the nodes that provide access to the network) used to manage a
   set of connections that provide end to end services. While
   connections require state to be maintained at nodes along the data
   path within the network, *** calls do not involve the participation
   of transit nodes except to forward the call management requests as
   transparent messages ***. Moreover, a call may be established and
   maintained independently of the connections that it supports.

   Also, there is a hierarchical relationship between calls and
   connections. One or more (or even no) connections may be associated
   with a given call but a connection can not be part of more than one
   call. A connection may, however, exist without a call. Moreover, the
   establishment of a call can be independent ("full call/connection
   separation") or simultaneous ("logical call/connection separation")
   from the connection setup (i.e. establishing a call before adding
   connections to the call or perform these operations simultaneously).

   Thus, with the introduction of the call concept, it is necessary to
   support a means of identifying the call. This becomes important when
   calls and connections are separated and a connection must contain a
   reference to its associated call. The following identification
   enables this hierarchy:
   - Call IDs are unique within the context of the pair of addresses

D.Papadimitriou et al. - Expires January 2006                       36
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


     that are the source and destination of the call.
   - Tunnel IDs are unique within the context of the Session (that is
     the destination of the Tunnel) and Tunnel IDs may be unique within
     the context of a Call.
   - LSP IDs are unique within the context of a Tunnel.

   For this purpose, [G.7713.2] introduces two new objects: a CALL_ID
   and a CALL_OPS object to be used in the Path, Resv, PathTear,
   PathErr, and Notify messages (note: additional requirements for
   ResvErr and ResvTear messages' support are not addressed). The
   CALL_OPS object is also referred to as a "call capability" object,
   since it specifies the capability of the call. These objects belongs
   to the range 224-255 defined as "RSVP will silently ignore, but
   FORWARD an object with a Class Number in this range that it does not
   understand."

   However, the solution described in [G.7713.2]:

   - Does not provide backward compatible extensions in support of full
     call/connection separation and thus only supports logical call/
     connection separation (i.e. a call with zero connections is not
     supported). This because node that does not implement [G.7713.2],
     will not process the CALL_OPS object, though it will establish the
     *connection* (while forwarding the "Call Setup" message), i.e.
     allocating labels and possibly attempting to reserve bandwidth.
     [G.7713.2] forbids this behavior by a transit node, but only a
     node implementing [G.7713.2] will know the difference between a
     call and a connection.

     In turn, the required signaling protocol independence between
     intra- and inter-domain reference points is broken: an operator
     does not have the possibility to use GMPLS [RFC3473] and must
     exclusively use [G.7713.2].

   - Does not describe how to support multiple connections per call but
     limits the description to a single connection per call. Further,
     in the case of complete call/connection separation, it does not
     describe how to add the first connection to the call.

   - Does not describe how to support multiple connections per call and
     limits the description to a single connection per call. Further,
     it does not describe how to add the first connection to the call
     when to support call/connection separation.

   - Does not specify any procedure for negotiating call ingress/egress
     node capabilities during call setup.

   - Does not allow for call support *independently* of the initiating/
     terminating nodes (the CALL_ID is attached to the ingress node)
     thus restricting the flexibility in terms of call identifiers.

   - Requires the inclusion of the CALL ID and CALL OPS objects in
     PathErr messages that may be generated at transit nodes, which do

D.Papadimitriou et al. - Expires January 2006                       37
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


     not implement [G.7713.2] and so do not support these objects.

4. Call Segments

   [G.7713.2] cannot, by definition, support call segments signaling
   mechanisms, as required in [G.8080] and [G.7713], since [G.7713.2]
   does not support full call/connection separation.

5. Control Plane Restart Capabilities

   Restart capabilities are provided by GMPLS RSVP-TE signaling in case
   of control plane failure including nodal and control channel faults.
   The handling of node and control channels faults is described in
   [RFC3473] Section 9. No additional RSVP mechanisms or objects are
   required to fulfill the ASON control plane restart capabilities.

   However, [G.7713.2] defines additional procedures for control plane
   recovery, three of them being considered in the context of an
   interaction with the management plane and thus outside the scope of
   the present document. The last one expects persistent state storage
   and the restart mechanism defined in [RFC3473] is to be used for
   verification of neighbor states, while the persistent storage
   provides the local recovery of lost state. However, per [RFC3473], if
   during the Hello synchronization the restarting node determines that
   a neighbor does not support state recovery and the restarting node
   maintains its local state on a per neighbor basis, the restarting
   node should immediately consider the Recovery as completed. Therefore,
   the procedure described in [G.7713.2] requires disabling state
   recovery on each neighboring node leading also to an unspecified
   verification procedure.

6. Extended Label Usage

   No specific GMPLS RSVP-TE extensions have been proposed in [G.7713.2]
   for extended label usage.

7. Crankback Signaling

   [G.7713.2] does not support crankback signaling mechanisms, as
   required in [G.8080] and [G.7713].

8. Security Considerations

   This is an informational draft and does not introduce any new
   security considerations.

   Please refer to each of the referenced documents for a description of
   the security considerations applicable to the features that they
   provide.

   Note that although [RFC3474] is an informational RFC it does document
   new protocol elements and functional behavior and as such introduces
   new security considerations. In particular, the ability to place

D.Papadimitriou et al. - Expires January 2006                       38
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


   authentication and policy details within the context of Call
   establishment may strengthen the options for security and may weaken
   the security of subsequent Connection establishment. Also the
   potential to subvert accidentally or deliberately a soft permanent
   connection by establishing the soft part of the connection from a
   false remote node needs to be examined. However, [RFC3474] has a
   minimal security considerations section.















































D.Papadimitriou et al. - Expires January 2006                       39
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt                   July 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at ietf-
   ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

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









D.Papadimitriou et al. - Expires January 2006                       40


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/