draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt   rfc4974.txt 
Network Working Group D. Papadimitriou (Alcatel)
Internet Draft A. Farrel (Old Dog Consulting)
Updates RFC 3473
Proposed Category: Standard Track
Expiration Date: July 2007 January 2007
Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions
in support of Calls
draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt
Status of this Memo Network Working Group D. Papadimitriou
Request for Comments: 4974 Alcatel
Updates: 3473 A. Farrel
Category: Standards Track Old Dog Consulting
August 2007
By submitting this Internet-Draft, each author represents that any Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions
applicable patent or other IPR claims of which he or she is aware in Support of Calls
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 Status of This Memo
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 This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet-Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as "work in progress." Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The IETF Trust (2007).
http://www.ietf.org/shadow.html.
Abstract Abstract
In certain networking topologies, it may be advantageous to maintain In certain networking topologies, it may be advantageous to maintain
associations between endpoints and key transit points to support an associations between endpoints and key transit points to support an
instance of a service. Such associations are known as Calls. instance of a service. Such associations are known as Calls.
A Call does not provide the actual connectivity for transmitting user A Call does not provide the actual connectivity for transmitting user
traffic, but only builds a relationship by which subsequent traffic, but only builds a relationship by which subsequent
Connections may be made. In Generalized MPLS (GMPLS) such Connections Connections may be made. In Generalized MPLS (GMPLS) such
are known as Label Switched Paths (LSPs). Connections are known as Label Switched Paths (LSPs).
This document specifies how GMPLS RSVP-TE signaling may be used and This document specifies how GMPLS Resource Reservation Protocol -
extended to support Calls. These mechanisms provide full and logical Traffic Engineering (RSVP-TE) signaling may be used and extended to
support Calls. These mechanisms provide full and logical
Call/Connection separation. Call/Connection separation.
The mechanisms proposed in this document are applicable to any The mechanisms proposed in this document are applicable to any
environment (including multi-area), and for any type of interface: environment (including multi-area), and for any type of interface:
packet, layer-2, time-division multiplexed, lambda, or fiber packet, layer-2, time-division multiplexed, lambda, or fiber
switching. switching.
Papadimitriou and Farrel January 2007 Table of Contents
Table of Content
1. Conventions used in this document ............................. 3
2. Introduction .................................................. 3
2.1 Applicability to ASON ........................................ 4
3. Requirements .................................................. 4
3.1 Basic Call Function .......................................... 4
3.2 Call/Connection Separation ................................... 4
3.3 Call Segments ................................................ 5
4. Concepts and Terms ............................................ 5
4.1 What is a Call? .............................................. 5
4.2 A Hierarchy of Calls, Connections, Tunnels and LSPs .......... 5
4.3 Exchanging Access Link Capabilities .......................... 6
4.3.1 Network-initiated Calls .................................... 7
4.3.2 User-initiated Calls ....................................... 7
4.3.3 Utilizing Call Setup ....................................... 7
5. Protocol Extensions for Calls and Connections ................. 8
5.1 Call Setup and Teardown ...................................... 8
5.2 Call Identification .......................................... 8
5.2.1 Long Form Call Identification .............................. 9
5.2.2 Short Form Call Identification ............................. 9
5.2.3 Short Form Call ID Encoding ................................ 9
5.3 LINK_CAPABILITY object ...................................... 10
5.4 Revised Message Formats ..................................... 11
5.4.1 Notify Message ............................................ 21
5.5 ADMIN_STATUS Object ......................................... 21
6. Procedures in Support of Calls and Connections ............... 32
6.1 Call/Connection Setup Procedures ............................ 32
6.2 Call Setup .................................................. 32
6.2.1 Accepting Call Setup ...................................... 54
6.2.2 Call Setup Failure and Rejection .......................... 65
6.3 Adding a Connections to a Call .............................. 65
6.3.1 Adding a Reverse Direction LSP to a Call .................. 76
6.4 Call-Free Connection Setup .................................. 76
6.5 Call Collision .............................................. 76
6.6 Call/Connection Teardown .................................... 87
6.6.1 Removal of a Connection from a Call ....................... 98
6.6.2 Removal of the Last Connection from a Call ................ 98
6.6.3 Teardown of an "Empty" Call ............................... 98
6.6.4 Attempted Teardown of a Call with Existing Connections .... 98
6.6.5 Teardown of a Call from the Egress ........................ 20
6.7 Control Plane Survivability ................................. 20
7. Applicability of Call and Connection Procedures .............. 21
7.1 Network-initiated Calls ..................................... 21
7.2 User-initiated Calls ........................................ 21
7.3 External Call Managers ...................................... 22
7.3.1 Call Segments ............................................. 22
8. Non-support of Call ID ....................................... 22
8.1 Non-Support by External Call Managers ....................... 23
8.2 Non-Support by Transit Node ................................. 23
Papadimitriou and Farrel January 2007
8.3 Non-Support by Egress Node .................................. 24
9. Security Considerations ...................................... 24
9.1 Call and Connection Security Considerations ................. 24
10. IANA Considerations ......................................... 25
10.1 RSVP Objects ............................................... 25
10.2 RSVP Error Codes and Error Values .......................... 25
10.3 RSVP ADMIN_STATUS object Bits .............................. 26
11. Acknowledgements ............................................ 26
12. References .................................................. 26
12.1 Normative References ....................................... 26
12.2 Informative References ..................................... 27
13. Contact Addresses ........................................... 28
14. Authors' Addresses .......................................... 28
1. 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 1. Introduction ....................................................3
terminology used in [RFC3471], [RFC3473], [RFC3477] and [RFC3945]. 1.1. Applicability to ASON ......................................4
2. Conventions Used in This document ...............................4
3. Requirements ....................................................4
3.1. Basic Call Function ........................................4
3.2. Call/Connection Separation .................................5
3.3. Call Segments ..............................................5
4. Concepts and Terms ..............................................5
4.1. What Is a Call? ............................................5
4.2. A Hierarchy of Calls, Connections, Tunnels, and LSPs .......6
4.3. Exchanging Access Link Capabilities ........................6
4.3.1. Network-Initiated Calls .............................7
4.3.2. User-Initiated Calls ................................7
4.3.3. Utilizing Call Setup ................................8
5. Protocol Extensions for Calls and Connections ...................8
5.1. Call Setup and Teardown ....................................8
5.2. Call Identification ........................................9
5.2.1. Long Form Call Identification .......................9
5.2.2. Short Form Call Identification ......................9
5.2.3. Short Form Call ID Encoding ........................10
5.3. LINK_CAPABILITY Object ....................................11
5.4. Revised Message Formats ...................................12
5.4.1. Notify Message .....................................12
5.5. ADMIN_STATUS Object .......................................13
6. Procedures in Support of Calls and Connections .................14
6.1. Call/Connection Setup Procedures ..........................14
6.2. Call Setup ................................................14
6.2.1. Accepting Call Setup ...............................16
6.2.2. Call Setup Failure and Rejection ...................16
6.3. Adding a Connections to a Call ............................17
6.3.1. Adding a Reverse Direction LSP to a Call ...........18
6.4. Call-Free Connection Setup ................................18
6.5. Call Collision ............................................18
6.6. Call/Connection Teardown ..................................19
6.6.1. Removal of a Connection from a Call ................20
6.6.2. Removal of the Last Connection from a Call .........20
6.6.3. Teardown of an "Empty" Call ........................20
6.6.4. Attempted Teardown of a Call with Existing
Connections ........................................20
6.6.5. Teardown of a Call from the Egress .................21
6.7. Control Plane Survivability ...............................21
7. Applicability of Call and Connection Procedures ................22
7.1. Network-Initiated Calls ...................................22
7.2. User-Initiated Calls ......................................23
7.3. External Call Managers ....................................23
7.3.1. Call Segments ......................................23
8. Non-Support of Call ID .........................................24
8.1. Non-Support by External Call Managers .....................24
8.2. Non-Support by Transit Node ...............................24
8.3. Non-Support by Egress Node ................................25
9. Security Considerations ........................................25
9.1. Call and Connection Security Considerations ...............25
10. IANA Considerations ...........................................26
10.1. RSVP Objects .............................................26
10.2. RSVP Error Codes and Error Values ........................27
10.3. RSVP ADMIN_STATUS Object Bits ............................27
11. Acknowledgements ..............................................27
12. References ....................................................28
12.1. Normative References .....................................28
12.2. Informative References ...................................29
2. Introduction 1. Introduction
This document defines protocol procedures and extensions to support This document defines protocol procedures and extensions to support
Calls within Generalized MPLS (GMPLS). Calls within Generalized MPLS (GMPLS).
A Call is an association between endpoints and possibly between key A Call is an association between endpoints and possibly between key
transit points (such as network boundaries) in support of an instance transit points (such as network boundaries) in support of an instance
of a service. The end-to-end association is termed a "Call," and the of a service. The end-to-end association is termed a "Call", and the
association between two transit points or between an endpoint and a association between two transit points or between an endpoint and a
transit point is termed a "Call Segment." An entity that processes a transit point is termed a "Call Segment". An entity that processes a
Call or Call Segment is called a "Call Manager." Call or Call Segment is called a "Call Manager".
A Call does not provide the actual connectivity for transmitting user A Call does not provide the actual connectivity for transmitting user
traffic, but only builds a relationship by which subsequent traffic, but only builds a relationship by which subsequent
Connections may be made. In GMPLS such Connections are known as Label Connections may be made. In GMPLS, such Connections are known as
Switched Paths (LSPs). This document does not modify Connection setup Label Switched Paths (LSPs). This document does not modify
procedures defined in [RFC3473], [RFC4208] and [STITCH]. Connections Connection setup procedures defined in [RFC3473], [RFC4208], and
set up as part of a Call follow the rules defined in these documents. [STITCH]. Connections set up as part of a Call follow the rules
defined in these documents.
A Call may be associated with zero, one, or more than one Connection, A Call may be associated with zero, one, or more than one Connection,
and a Connection may be associated with zero or one Call. Thus full and a Connection may be associated with zero or one Call. Thus, full
and logical Call/Connection separation is needed. and logical Call/Connection separation is needed.
An example of the requirement for Calls can be found in the ITU-T's An example of the requirements for Calls can be found in the ITU-T's
Automatically Switched Optical Network (ASON) architecture [G.8080] Automatically Switched Optical Network (ASON) architecture [G.8080]
and specific requirements for support of Calls in this context can be and specific requirements for support of Calls in this context can be
found in [RFC4139]. Note, however, that while the mechanisms found in [RFC4139]. Note, however, that while the mechanisms
Papadimitriou and Farrel January 2007
described in this document meet the requirements stated in [RFC4139], described in this document meet the requirements stated in [RFC4139],
they have wider applicability. they have wider applicability.
The mechanisms defined in this document are equally applicable to any The mechanisms defined in this document are equally applicable to any
packet (PSC) interface, layer-2 interfaces (L2SC), TDM capable packet (PSC) interface, layer-2 interfaces (L2SC), TDM capable
interfaces, LSC interfaces, or FSC interfaces. The mechanisms and interfaces, LSC interfaces, or FSC interfaces. The mechanisms and
protocol extensions are backward compatible, and can be used for Call protocol extensions are backward compatible, and can be used for Call
management where only the Call Managers need to be aware of the management where only the Call Managers need to be aware of the
protocol extensions. protocol extensions.
2.1 Applicability to ASON 1.1. Applicability to ASON
[RFC4139] details the requirements on GMPLS signaling to satisfy the [RFC4139] details the requirements on GMPLS signaling to satisfy the
ASON architecture described in [G.8080]. The mechanisms described in ASON architecture described in [G.8080]. The mechanisms described in
this document meet the requirements for Calls as described in this document meet the requirements for Calls as described in
Sections 4.2 and 4.3 of [RFC4139] and the additional Call-related Sections 4.2 and 4.3 of [RFC4139] and the additional Call-related
requirements in Sections 4.4, 4.7, 5 and 6 of [RFC4139]. requirements in Sections 4.4, 4.7, 5, and 6 of [RFC4139].
[ASON-APPL] describes the applicability of GMPLS protocols to the [ASON-APPL] describes the applicability of GMPLS protocols to the
ASON architecture. ASON architecture.
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. Requirements 3. Requirements
3.1 Basic Call Function 3.1. Basic Call Function
The Call concept is used to deliver the following capabilities. The Call concept is used to deliver the following capabilities:
- Verification and identification of the Call initiator (prior to - Verification and identification of the Call initiator (prior to
LSP setup). LSP setup).
- Support of virtual concatenation with diverse path component LSPs. - Support of virtual concatenation with diverse path component LSPs.
- Association of multiple LSPs with a single Call (note aspects - Association of multiple LSPs with a single Call (note aspects
related to recovery are detailed in [RFC4426] and [GMPLS-E2E]). related to recovery are detailed in [RFC4426] and [GMPLS-E2E]).
- Facilitation of control plane operations by allowing operational - Facilitation of control plane operations by allowing an
status change of the associated LSP. operational status change of the associated LSP.
Procedures and protocol extensions to support Call setup, and the Procedures and protocol extensions to support Call setup, and the
association of Calls with Connections are described in Section 5 and association of Calls with Connections are described in Section 5 and
onwards of this document. onwards of this document.
3.2 Call/Connection Separation 3.2. Call/Connection Separation
Full and logical Call and Connection separation is required. That is: Full and logical Call and Connection separation is required. That
is:
- It MUST be possible to establish a Connection without dependence - It MUST be possible to establish a Connection without dependence
on a Call. on a Call.
Papadimitriou and Farrel January 2007
- It MUST be possible to establish a Call without any associated - It MUST be possible to establish a Call without any associated
Connections. Connections.
- It MUST be possible to associate more than one Connection with a - It MUST be possible to associate more than one Connection with a
Call. Call.
- Removal of the last Connection associated with a Call SHOULD NOT - Removal of the last Connection associated with a Call SHOULD NOT
result in the automatic removal of the Call except as a matter of result in the automatic removal of the Call except as a matter of
local policy at the ingress of the Call. local policy at the ingress of the Call.
- Signaling of a Connection associated with a Call MUST NOT require - Signaling of a Connection associated with a Call MUST NOT require
the distribution or retention of Call-related information (state) the distribution or retention of Call-related information (state)
within the network. within the network.
3.3 Call Segments 3.3. Call Segments
Call Segment capabilities MUST be supported. Call Segment capabilities MUST be supported.
Procedures and (GMPLS) RSVP-TE signaling protocol extensions to Procedures and (GMPLS) RSVP-TE signaling protocol extensions to
support Call Segments are described in Section 7.3.1 of this support Call Segments are described in Section 7.3.1 of this
document. document.
4. Concepts and Terms 4. Concepts and Terms
The concept of a Call and a Connection are also discussed in the ASON The concept of a Call and a Connection are also discussed in the ASON
architecture [G.8080] and [RFC4139]. This section is not intended as architecture [G.8080] and [RFC4139]. This section is not intended as
a substitute for those documents, but is a brief summary of the key a substitute for those documents, but is a brief summary of the key
terms and concepts. terms and concepts.
4.1 What is a Call? 4.1. What Is a Call?
A Call is an agreement between endpoints possibly in cooperation with A Call is an agreement between endpoints possibly in cooperation with
the nodes that provide access to the network. Call setup may include the nodes that provide access to the network. Call setup may include
capability exchange, policy, authorization and security. capability exchange, policy, authorization, and security.
A Call is used to facilitate and manage a set of Connections that A Call is used to facilitate and manage a set of Connections that
provide end to end data services. While Connections require state to provide end-to-end data services. While Connections require state to
be maintained at nodes along the data path within the network, Calls be maintained at nodes along the data path within the network, Calls
do not involve the participation of transit nodes except to forward do not involve the participation of transit nodes except to forward
the Call management requests as transparent messages. the Call management requests as transparent messages.
A Call may be established and maintained independently of the A Call may be established and maintained independently of the
Connections that it supports. Connections that it supports.
4.2 A Hierarchy of Calls, Connections, Tunnels and LSPs 4.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 with a Call. A
Connection may not be part of more than one Call. A Connection may,
however, exist without a Call.
Papadimitriou and Farrel January 2007 Clearly, there is a hierarchical relationship between Calls and
Connections. One or more Connections may be associated with 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 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 TE Tunnel. Commonly, a Tunnel is identified with a single LSP, but
should be noted that for protection, load balancing and many other it should be noted that for protection, load balancing, and many
functions, a Tunnel may be supported by multiple parallel LSPs. The other functions, a Tunnel may be supported by multiple parallel LSPs.
following identification reproduces this hierarchy. The following identification reproduces this hierarchy.
- Call IDs are unique within the context of the pair of addresses - Call IDs are unique within the context of the pair of addresses
that are the source and destination of the Call. that are the source and destination of the Call.
- Tunnel IDs are unique within the context of the Session (that is - Tunnel IDs are unique within the context of the Session (that is
the destination of the Tunnel). Applications may also find it the destination of the Tunnel). Applications may also find it
convenient to keep the Tunnel ID unique within the context of a convenient to keep the Tunnel ID unique within the context of a
Call. Call.
- LSP IDs are unique within the context of a Tunnel. - 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 Note that the Call_ID value of zero is reserved and MUST NOT be used
during LSP-independent Call establishment. during LSP-independent Call establishment.
Throughout the remainder of this document, the terms LSP and Tunnel Throughout the remainder of this document, the terms LSP and Tunnel
are used interchangeably with the term Connection. The case of a are used interchangeably with the term Connection. The case of a
Tunnel that is supported by more than one LSP is covered implicitly. Tunnel that is supported by more than one LSP is covered implicitly.
4.3 Exchanging Access Link Capabilities 4.3. Exchanging Access Link Capabilities
In an overlay model, it is useful for the ingress node of an LSP to In an overlay model, it is useful for the ingress node of an LSP to
know the link capabilities of the link between the network and the know the link capabilities of the link between the network and the
remote overlay network. In the language of [RFC4208], the ingress remote overlay network. In the language of [RFC4208], the ingress
node can make use of information about the link between the egress node can make use of information about the link between the egress
network node (NN) and the remote edge node (EN). We call this link core node (CN) and the remote edge node (EN). We call this link the
the egress network link. This information may allow the ingress node egress network link. This information may allow the ingress node to
to tailor its LSP request to fit those capabilities and to better tailor its LSP request to fit those capabilities and to better
utilize network resources with regard to those capabilities. utilize network resources with regard to those capabilities.
For example, this might be used in transparent optical networks to For example, this might be used in transparent optical networks to
supply information on lambda availability on egress network links, supply information on lambda availability on egress network links,
or, where the egress NN is capable of signal regeneration, it might or, where the egress CN is capable of signal regeneration, it might
provide a mechanism for negotiating signal quality attributes (such provide a mechanism for negotiating signal quality attributes (such
as bit error rate). Similarly, in multi-domain routing environments as bit error rate). Similarly, in multi-domain routing environments,
it could be used to provide end-to-end selection of component links it could be used to provide end-to-end selection of component links
(i.e., spatial attribute negotiation) where TE links have been (i.e., spatial attribute negotiation) where TE links have been
bundled based on technology specific attributes. bundled based on technology specific attributes.
In some circumstances, the Traffic Engineering Database (TED) may In some circumstances, the Traffic Engineering Database (TED) may
contain sufficient information for decisions to be made about which contain sufficient information for decisions to be made about which
egress network link to use. In other circumstances, the TED might not egress network link to use. In other circumstances, the TED might
contain this information and Call setup may provide a suitable not contain this information and Call setup may provide a suitable
mechanism to exchange information for this purpose. The mechanism to exchange information for this purpose. The Call-
Call-responder may use the Call parameters to select a subset of the responder may use the Call parameters to select a subset of the
available egress network links between the egress NN and the remote available egress network links between the egress CN and the remote
Papadimitriou and Farrel January 2007
EN, and may report these links and their capabilities on the Call EN, and may report these links and their capabilities on the Call
response so that the Call-initiator may select a suitable link. response so that the Call-initiator may select a suitable link.
The sections that follow indicate the cases where the TED may be The sections that follow indicate the cases where the TED may be
used, and those where Call parameter exchange may be appropriate. used, and those where Call parameter exchange may be appropriate.
4.3.1 Network-initiated Calls 4.3.1. Network-Initiated Calls
Network-initiated Calls arise when the ingress (and correspondingly Network-initiated Calls arise when the ingress (and correspondingly
the egress) lie within the network and there may be no need to the egress) lie within the network and there may be no need to
distribute additional link capability information over and above the distribute additional link capability information over and above the
information distributed by the TE and GMPLS extensions to the IGP. information distributed by the TE and GMPLS extensions to the IGP.
Further, it is possible that future extensions to these IGPs will Further, it is possible that future extensions to these IGPs will
allow the distribution of more detailed information including optical allow the distribution of more detailed information including optical
impairments. impairments.
4.3.2 User-initiated Calls 4.3.2. User-Initiated Calls
User-initiated Calls arise when the ingress (and correspondingly the User-initiated Calls arise when the ingress (and correspondingly the
egress) lie outside the network. Edge link information may not be egress) lie outside the network. Edge link information may not be
visible within the core network, nor (and specifically) at other edge visible within the core network, nor (and specifically) at other edge
nodes. This may prevent an ingress from requesting suitable LSP nodes. This may prevent an ingress from requesting suitable LSP
characteristics to ensure successful LSP setup. characteristics to ensure successful LSP setup.
Various solutions to this problem exist, including the definition of Various solutions to this problem exist, including the definition of
static TE links (that is, not advertised by a routing protocol) static TE links (that is, not advertised by a routing protocol)
between the NNs and ENs. Nevertheless, special procedures may be between the CNs and ENs. Nevertheless, special procedures may be
necessary to advertise to the edge nodes outside of the network necessary to advertise to the edge nodes outside of the network
information about egress network links without also advertising the information about egress network links without also advertising the
information specific to the contents of the network. information specific to the contents of the network.
In the future, when the requirements on the information that needs to In the future, when the requirements on the information that needs to
be supported are better understood, TE extensions to EGPs may be be supported are better understood, TE extensions to EGPs may be
defined that provide this function, and new rules for leaking TE defined to provide this function, and new rules for leaking TE
information between routing instances may be used. information between routing instances may be used.
4.3.3 Utilizing Call Setup 4.3.3. Utilizing Call Setup
When IGP and EGP solutions are not available at the User-to-Network When IGP and EGP solutions are not available at the User-to-Network
Interface (UNI), there is still a requirement to have, at the local Interface (UNI), there is still a requirement to have the knowledge
edge nodes, the knowledge of the remote edge link capabilities. of the remote edge link capabilities at the local edge nodes.
The Call setup procedure provides an opportunity to discover edge The Call setup procedure provides an opportunity to discover edge
link capabilities of remote edge nodes before LSP setup is attempted. link capabilities of remote edge nodes before LSP setup is attempted.
- The Call-responder can return information on one or more egress - The Call-responder can return information on one or more egress
network links. The Call-reponder could return a full list of the network links. The Call-responder could return a full list of the
available links with information about the link capabilities, or it available links with information about the link capabilities, or
could filter the list to return information about only those links it could filter the list to return information about only those
which might be appropriate to support the Connections needed by the links that might be appropriate to support the Connections needed
by the Call. To do this second option, the Call-responder must
Papadimitriou and Farrel January 2007 determine such appropriate links from information carried in the
Call request including destination of the Call, and the level of
Call. To do this second option, the Call-responder must determine service (bandwidth, protection, etc.) required.
such appropriate links from information carried in the Call request
including destination of the Call, and the level of service
(bandwidth, protection, etc.) required.
- On receiving a Call response, the Call-initiator must determine - On receiving a Call response, the Call-initiator must determine
paths for the Connections (LSPs) that it will set up. The way that paths for the Connections (LSPs) that it will set up. The way
it does this is out of scope for this document since it is an that it does this is out of scope for this document since it is an
implementation-specific, algorithmic process. However, it can take implementation-specific, algorithmic process. However, it can
as input the information about the available egress network links take as input the information about the available egress network
as supplied in the Call response. links as supplied in the Call response.
The LINK_CAPABILITY object is defined to allow this information to be The LINK_CAPABILITY object is defined to allow this information to be
exchanged. The information that is included in this object is similar exchanged. The information that is included in this object is
to that distributed by GMPLS-capable IGPs (see [RFC4202]). similar to that distributed by GMPLS-capable IGPs (see [RFC4202]).
5. Protocol Extensions for Calls and Connections 5. Protocol Extensions for Calls and Connections
This section describes the protocol extensions needed in support of This section describes the protocol extensions needed in support of
Call identification and management of Calls and Connections. Call identification and management of Calls and Connections.
Procedures for the use of these protocol extensions are described in Procedures for the use of these protocol extensions are described in
Section 6. Section 6.
5.1 Call Setup and Teardown 5.1. Call Setup and Teardown
Calls are established independently of Connections through the use of Calls are established independently of Connections through the use of
the Notify message. The Notify message is a targeted message and does the Notify message. The Notify message is a targeted message and
not need to follow the path of LSPs through the network. does not need to follow the path of LSPs through the network.
Simultaneous Call and Connection establishment (sometimes referred to Simultaneous Call and Connection establishment (sometimes referred to
as piggybacking) is not supported. as piggybacking) is not supported.
5.2 Call Identification 5.2. Call Identification
As soon as the concept of a Call is introduced, it is necessary to As soon as the concept of a Call is introduced, it is necessary to
support some means of identifying the Call. This becomes particularly support some means of identifying the Call. This becomes
important when Calls and Connections are separated and Connections particularly important when Calls and Connections are separated and
must contain some reference to the Call. Connections must contain some reference to the Call.
A Call may be identified by a sequence of bytes that may have 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 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 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 rules for encoding or parsing Call IDs, but it must provide a
suitable means to communicate Call IDs within the protocol. The full suitable means to communicate Call IDs within the protocol. The full
Call identification is referred to as the long Call ID. Call identification is referred to as the long Call ID.
The Call_ID is only relevant at the sender and receiver nodes. The Call_ID is only relevant at the sender and receiver nodes.
Maintenance of this information in the signaling state is not Maintenance of this information in the signaling state is not
mandated at any intermediate node. Thus no change in [RFC3473] mandated at any intermediate node. Thus, no change in [RFC3473]
transit implementations is required and there are no backward transit implementations is required and there are no backward
Papadimitriou and Farrel January 2007
compatibility issues. Forward compatibility is maintained by using compatibility issues. Forward compatibility is maintained by using
the existing default values to indicate that no Call processing is the existing default values to indicate that no Call processing is
required. required.
Further, the long Call ID is not required as part of the Connection Further, the long Call ID is not required as part of the Connection
(LSP) state even at the sender and receiver nodes so long as some (LSP) state even at the sender and receiver nodes so long as some
form of correlation is available. This correlation is provided form of correlation is available. This correlation is provided
through the short Call ID. through the short Call ID.
5.2.1 Long Form Call Identification 5.2.1. Long Form Call Identification
The long Call ID is only required on the Notify message used to The long Call ID is only required on the Notify message used to
establish the Call. It is carried in the "Session Name" field of the establish the Call. It is carried in the "Session Name" field of the
SESSION_ATTRIBUTE Object on the Notify message. SESSION_ATTRIBUTE object on the Notify message.
A unique value per Call is inserted in the "Session Name" field by A unique value per Call is inserted in the "Session Name" field by
the initiator of the Call. Subsequent network nodes MAY inspect this the initiator of the Call. Subsequent core nodes MAY inspect this
object and MUST forward this object transparently across network object and MUST forward this object transparently across network
interfaces until reaching the egress node. Note that the structure of interfaces until reaching the egress node. Note that the structure
this field MAY be the object of further formatting depending on the of this field MAY be the object of further formatting depending on
naming convention(s). However, [RFC3209] defines the "Session Name" the naming convention(s). However, [RFC3209] defines the "Session
field as a Null padded display string, and that any formatting Name" field as a Null padded display string, so any formatting
conventions for the Call ID must be limited to this scope. conventions for the Call ID must be limited to this scope.
5.2.2 Short Form Call Identification 5.2.2. Short Form Call Identification
The Connections (LSPs) associated with a Call need to carry a The Connections (LSPs) associated with a Call need to carry a
reference to the Call - the short Call ID. A new field is added to reference to the Call - the short Call ID. A new field is added to
the signaling protocol to identify an individual LSP with the Call to the signaling protocol to identify an individual LSP with the Call to
which it belongs. which it belongs.
The new field is a 16-bit identifier (unique within the context of 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 the address pairing provided by the Tunnel_End_Point_Address and the
Sender_Address of the SENDER TEMPLATE object) that MUST be exchanged Sender_Address of the SENDER_TEMPLATE object) that MUST be exchanged
on the Notify message during Call initialization and is used on all on the Notify message during Call initialization and is used on all
subsequent LSP messages that are associated with the Call. This subsequent LSP messages that are associated with the Call. This
identifier is known as the short Call ID and is encoded as described identifier is known as the short Call ID and is encoded as described
in Section 5.2.3. The Call ID MUST NOT be used as part of the in Section 5.2.3. The Call ID MUST NOT be used as part of the
processing to determine the session to which an RSVP signaling processing to determine the session to which an RSVP signaling
message applies. This does not generate any backward compatibility message applies. This does not generate any backward compatibility
issue since the reserved field of the SESSION object defined in issue since the reserved field of the SESSION object defined in
[RFC3209] MUST NOT be examined on receipt. [RFC3209] MUST NOT be examined on receipt.
In the unlikely case of short Call_ID exhaustion, local node policy In the unlikely case of short Call_ID exhaustion, local node policy
decides upon specific actions to be taken, but might include the use decides upon specific actions to be taken, but might include the use
of second Sender_Address. Local policy details are outside of the of second Sender_Address. Local policy details are outside of the
scope of this document. scope of this document.
Papadimitriou and Farrel January 2007 5.2.3. Short Form Call ID Encoding
5.2.3 Short Form Call ID Encoding
The short Call ID is carried in a 16-bit field in the SESSION object The short Call ID is carried in a 16-bit field in the SESSION object
carried on the Notify message used during Call setup, and on all carried on the Notify message used during Call setup, and on all
messages during LSP setup and management. The field used was messages during LSP setup and management. The field used was
previously reserved (MUST be set to zero on transmission and ignored previously reserved (MUST be set to zero on transmission and ignored
on receipt). This ensures backward compatibility with nodes that do on receipt). This ensures backward compatibility with nodes that do
not utilize Calls. not utilize Calls.
The figure below shows the new version of the object. The figure below shows the new version of the object.
Class = SESSION, Class-Num = 1, C-Type = 7(IPv4)/8(IPv6) Class = SESSION, Class-Num = 1, C-Type = 7(IPv4)/8(IPv6)
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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 ~ ~ IPv4/IPv6 Tunnel End Point Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call_ID | Tunnel ID | | Call_ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4/IPv6 Tunnel End Point Address: 32 bits/128 bits (see [RFC3209]) IPv4/IPv6 Tunnel End Point Address: 32 bits/128 bits (see [RFC3209])
Call_ID: 16 bits Call_ID: 16 bits
A 16-bit identifier used in the SESSION object that remains A 16-bit identifier used in the SESSION object that remains
constant over the life of the Call. The Call_ID value MUST be constant over the life of the Call. The Call_ID value MUST be set
set to zero when there is no corresponding Call. to zero when there is no corresponding Call.
Tunnel ID: 16 bits (see [RFC3209]) Tunnel ID: 16 bits (see [RFC3209])
Extended Tunnel ID: 32 bits/128 bits (see [RFC3209]) Extended Tunnel ID: 32 bits/128 bits (see [RFC3209])
5.3 LINK_CAPABILITY object 5.3. LINK_CAPABILITY Object
The LINK_CAPABILITY object is introduced to support link capability The LINK_CAPABILITY object is introduced to support link capability
exchange during Call setup and MAY be included in a Notify message exchange during Call setup and MAY be included in a Notify message
used for Call setup. This optional object includes the link local used for Call setup. This optional object includes the link-local
capabilities of a link joining the Call-initiating node (or capabilities of a link joining the Call-initiating node (or Call-
Call-terminating node) to the network. The specific node is indicated terminating node) to the network. The specific node is indicated by
by the source address of the Notify message. the source address of the Notify message.
The link reported can be a single link or can be a bundled link The link reported can be a single link or can be a bundled link
[RFC4201]. [RFC4201].
The Class Number is selected so that the nodes that do not recognize 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 this object drop it silently. That is, the top bit is set and the
next bit is clear. next bit is clear.
Papadimitriou and Farrel January 2007
This object has the following format: This object has the following format:
Class-Num = TBA (form 10bbbbbb), C_Type = 1 Class-Num = 133 (form 10bbbbbb), C_Type = 1
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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) // // (Subobjects) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents of the LINK_CAPABILITY object is defined as series of The contents of the LINK_CAPABILITY object is defined as a series of
variable-length data items called subobjects. The subobject format is variable-length data items called subobjects. The subobject format
defined in [RFC3209]. is defined in [RFC3209].
The following subobjects are currently defined. The following subobjects are currently defined.
- Type 1: the link local IPv4 address of a link or a numbered bundle - Type 1: the link local IPv4 address of a link or a numbered bundle
using the format defined in [RFC3209] using the format defined in [RFC3209].
- Type 2: the link local IPv6 address of a link or a numbered bundle - Type 2: the link local IPv6 address of a link or a numbered bundle
using the format defined in [RFC3209] using the format defined in [RFC3209].
- Type 4: the link local identifier of an unnumbered link or bundle - Type 4: the link local identifier of an unnumbered link or bundle
using the format defined in [RFC3477] using the format defined in [RFC3477].
- Type 64: the Maximum Reservable Bandwidth corresponding to this - Type 64: the Maximum Reservable Bandwidth corresponding to this
link or bundle (see [RFC4201]) link or bundle (see [RFC4201]).
- Type 65: the interface switching capability descriptor (see - Type 65: the interface switching capability descriptor (see
[RFC4202]) corresponding to this link or bundle (see also [RFC4202]) corresponding to this link or bundle (see also
[RFC4201]). [RFC4201]).
Note: future revisions of this document may extend the above list. Note: future revisions of this document may extend the above list.
A single instance of this object MAY be used to exchange capablity A single instance of this object MAY be used to exchange capability
information relating to more than one link or bundled link. In this information relating to more than one link or bundled link. In this
case, the following ordering MUST be used: case, the following ordering MUST be used:
- each link MUST be identified by an identifier subobject (Type 1, 2
or 4) - each link MUST be identified by an identifier subobject (Type 1,
2, or 4)
- capability subobjects (Type 64 or 65, and future subobjects) MUST - capability subobjects (Type 64 or 65, and future subobjects) MUST
be placed after the identifier subobject for the link or bundle to be placed after the identifier subobject for the link or bundle to
which they refer. which they refer.
Mulitple instances of the LINK_CAPABILITY object within the same Multiple instances of the LINK_CAPABILITY object within the same
Notify message are not supported by this specification. In the event Notify message are not supported by this specification. In the event
that a Notify message contains multiple LINK_CAPABILITY objects, the that a Notify message contains multiple LINK_CAPABILITY objects, the
receiver SHOULD process the first one as normal and SHOULD ignore receiver SHOULD process the first one as normal and SHOULD ignore
subsequent instances of the object. subsequent instances of the object.
5.4 Revised Message Formats 5.4. Revised Message Formats
The Notify message is enhanced to support Call establishment and The Notify message is enhanced to support Call establishment and
teardown of Calls. See Section 6 for a description of the procedures. teardown of Calls. See Section 6 for a description of the
procedures.
Papadimitriou and Farrel January 2007
5.4.1 Notify Message 5.4.1. Notify Message
The Notify message is modified in support of Call establishment by The Notify message is modified in support of Call establishment by
the optional addition of the LINK CAPABILTY object. Further, the the optional addition of the LINK_CAPABILITY object. Further, the
SESSION ATTRIBUTE object is added to the <notify session> sequence to SESSION_ATTRIBUTE object is added to the <notify session> sequence to
carry the long Call ID. The presence of the SESSION ATTRIBUTE object carry the long Call ID. The presence of the SESSION_ATTRIBUTE object
MAY be used to distinguish a Notify message used for Call management, MAY be used to distinguish a Notify message used for Call management,
but see Section 5.5 for another mechanism. The <notify session list> but see Section 5.5 for another mechanism. The <notify session list>
MAY be used to simultaneously set up multiple Calls. MAY be used to simultaneously set up multiple Calls.
The format of the Notify Message is as follows: The format of the Notify Message is as follows:
<Notify message> ::= <Common Header> [ <INTEGRITY> ] <Notify message> ::= <Common Header> [ <INTEGRITY> ]
[[ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]...] [[ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]...]
[ <MESSAGE_ID> ] [ <MESSAGE_ID> ]
<ERROR_SPEC> <ERROR_SPEC>
skipping to change at page 12, line 37 skipping to change at page 13, line 25
<notify session> ::= <SESSION> [ <ADMIN_STATUS> ] <notify session> ::= <SESSION> [ <ADMIN_STATUS> ]
[ <POLICY_DATA>...] [ <POLICY_DATA>...]
[ <LINK_CAPABILITY> ] [ <LINK_CAPABILITY> ]
[ <SESSION_ATTRIBUTE> ] [ <SESSION_ATTRIBUTE> ]
[ <sender descriptor> | <flow descriptor> ] [ <sender descriptor> | <flow descriptor> ]
<sender descriptor> ::= see [RFC3473] <sender descriptor> ::= see [RFC3473]
<flow descriptor> ::= see [RFC3473] <flow descriptor> ::= see [RFC3473]
5.5 ADMIN_STATUS Object 5.5. ADMIN_STATUS Object
Notify messages exchanged for Call control and management purposes Notify messages exchanged for Call control and management purposes
carry a specific new bit (the Call Management or C bit) in the ADMIN carry a specific new bit (the Call Management or C bit) in the
STATUS object. ADMIN_STATUS object.
[RFC3473] indicates that the format and contents of the ADMIN_STATUS [RFC3473] indicates that the format and contents of the ADMIN_STATUS
object are as defined in [RFC3471]. The new "C" bit is added for Call object are as defined in [RFC3471]. The new "C" bit is added for
control as shown below. Call control as shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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| |R| Reserved |C|T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reflect (R): 1 bit - see [RFC3471] Reflect (R): 1 bit - see [RFC3471]
Testing (T): 1 bit - see [RFC3471] Testing (T): 1 bit - see [RFC3471]
Administratively down (A): 1 bit - see [RFC3471] Administratively down (A): 1 bit - see [RFC3471]
Deletion in progress (D): 1 bit - see [RFC3471] Deletion in progress (D): 1 bit - see [RFC3471]
Papadimitriou and Farrel January 2007
Call Management (C): 1 bit Call Management (C): 1 bit
This bit is set when the message is being used to control This bit is set when the message is being used to control
and manage a Call. and manage a Call.
The procedures for the use of the C bit are described in Section 6. The procedures for the use of the C bit are described in Section 6.
6. Procedures in Support of Calls and Connections 6. Procedures in Support of Calls and Connections
6.1 Call/Connection Setup Procedures 6.1. Call/Connection Setup Procedures
This section describes the processing steps for Call and Connection This section describes the processing steps for Call and Connection
setup. setup.
There are three cases considered: There are three cases considered:
- A Call is set up without any associated - A Call is set up without any associated Connection. It is assumed
Connection. It is assumed that Connections will be added to the that Connections will be added to the Call at a later time, but
Call at a later time, but this is neither a requirement nor this is neither a requirement nor a constraint.
a constraint.
- A Connection may be added to an existing Call. This may happen if - A Connection may be added to an existing Call. This may happen if
the Call was set up without any associated Connections, or if the Call was set up without any associated Connections, or if
another Connection is added to a Call that already has one or more another Connection is added to a Call that already has one or more
associated Connections. associated Connections.
- A Connection may be established without any reference to a Call - A Connection may be established without any reference to a Call
(see Section 6.4). This encompasses the previous LSP setup (see Section 6.4). This encompasses the previous LSP setup
procedure. procedure.
Note that a Call MUST NOT be imposed upon a Connection that is Note that a Call MUST NOT be imposed upon a Connection that is
already established. To do so would require changing the short Call already established. To do so would require changing the short Call
ID in the SESSION OBJECT of the existing LSPs and this would ID in the SESSION object of the existing LSPs and this would
constitute a change in the Session Identifier. This is not allowed by constitute a change in the Session Identifier. This is not allowed
existing protocol specifications. by existing protocol specifications.
Call and Connection teardown procedures are described later in Call and Connection teardown procedures are described later in
Section 6.6. Section 6.6.
6.2 Call Setup 6.2. Call Setup
A Call is set up before, and independent of, LSP (i.e. Connection) A Call is set up before, and independent of, LSP (i.e., Connection)
setup. setup.
Call setup MAY necessitate verification of the link status and link Call setup MAY necessitate verification of the link status and link
capability negotiation between the Call ingress node and the Call capability negotiation between the Call ingress node and the Call
egress node. The procedure described below is applied only once for a egress node. The procedure described below is applied only once for
Call and hence only once for the set of LSPs associated with a Call. a Call and hence only once for the set of LSPs associated with a
Call.
Papadimitriou and Farrel January 2007
The Notify message (see [RFC3473]) is used to signal the Call setup The Notify message (see [RFC3473]) is used to signal the Call setup
request and response. The new Call Management (C) bit in the request and response. The new Call Management (C) bit in the
ADMIN_STATUS object is used to indicate that this Notify is managing ADMIN_STATUS object is used to indicate that this Notify is managing
a Call. The Notify message is sent with source and destination a Call. The Notify message is sent with source and destination
IPv4/IPv6 addresses set to any of the routable ingress/egress node IPv4/IPv6 addresses set to any of the routable ingress/egress node
addresses respectively. addresses respectively.
At least one session MUST be listed in the <notify session list> of 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 the Notify message. In order to allow for long identification of the
Call, the SESSION_ATTRIBUTE object is added as part of the <notify Call, the SESSION_ATTRIBUTE object is added as part of the <notify
session list>. Note that the ERROR SPEC object is not relevant in session list>. Note that the ERROR_SPEC object is not relevant in
Call setup and MUST carry the Error Code zero ("Confirmation") to Call setup and MUST carry the Error Code zero ("Confirmation") to
indicate that there is no error. indicate that there is no error.
During Call setup, the ADMIN STATUS object is sent with the following During Call setup, the ADMIN_STATUS object is sent with the following
bits set. Bits not listed MUST be set to zero. bits set. Bits not listed MUST be set to zero.
R - to cause the egress to respond R - to cause the egress to respond
C - to indicate that the Notify message is managing a Call. C - to indicate that the Notify message is managing a Call.
The SESSION, SESSION ATTRIBUTE, SENDER_TEMPLATE, SENDER_TSPEC objects The SESSION, SESSION_ATTRIBUTE, SENDER_TEMPLATE, SENDER_TSPEC objects
included in the <notify session> of the Notify message are built as included in the <notify session> of the Notify message are built as
follows. follows.
- The SESSION object includes as Tunnel_End_Point_Address any of the - The SESSION object includes as Tunnel_End_Point_Address any of the
Call-terminating (egress) node's IPv4/IPv6 routable addresses. The Call-terminating (egress) node's IPv4/IPv6 routable addresses.
Call_ID is set to a non-zero value unique within the context of The Call_ID is set to a non-zero value unique within the context
the address pairing provided by the Tunnel_End_Point_Address and of the address pairing provided by the Tunnel_End_Point_Address
the Sender_Address from the SENDER TEMPLATE object (see below). and the Sender_Address from the SENDER_TEMPLATE object (see
This value will be used as the short Call ID carried on all below). This value will be used as the short Call ID carried on
messages for LSPs associated with this Call. all messages for LSPs associated with this Call.
Note that the Call_ID value of zero is reserved and MUST NOT be Note that the Call_ID value of zero is reserved and MUST NOT be
used since it will be present in SESSION objects of LSPs used since it will be present in SESSION objects of LSPs that are
that are not associated with Calls. The Tunnel_ID of not associated with Calls. The Tunnel_ID of the SESSION object is
the SESSION object is not relevant for this procedure and SHOULD not relevant for this procedure and SHOULD be set to zero. The
be set to zero. The Extended_Tunnel_ID of the SESSION object is Extended_Tunnel_ID of the SESSION object is not relevant for this
not relevant for this procedure and MAY be set to zero or to an procedure and MAY be set to zero or to an address of the ingress
address of the ingress node. node.
- The SESSION ATTRIBUTE object contains priority flags. Currently no - The SESSION_ATTRIBUTE object contains priority flags. Currently
use of these flags is envisioned, however, future work may no use of these flags is envisioned, however, future work may
identify value in assigning priorities to Calls; accordingly the identify value in assigning priorities to Calls; accordingly the
Priority fields MAY be set to non-zero values. None of the Flags Priority fields MAY be set to non-zero values. None of the Flags
in the SESSION ATTRIBUTE object is relevant to this process and in the SESSION_ATTRIBUTE object is relevant to this process and
this field SHOULD be set to zero. The Session Name field is used this field SHOULD be set to zero. The Session Name field is used
to carry the long Call Id as described in Section 5. to carry the long Call Id as described in Section 5.
Papadimitriou and Farrel January 2007
- The SENDER_TEMPLATE object includes as Sender Address any of the - The SENDER_TEMPLATE object includes as Sender Address any of the
Call-initiating (ingress) node's IPv4/IPv6 routable addresses. The Call-initiating (ingress) node's IPv4/IPv6 routable addresses.
LSP_ID is not relevant and SHOULD be set to zero. The LSP_ID is not relevant and SHOULD be set to zero.
- The bandwidth value inserted in the SENDER_TSPEC and FLOWSPEC - The bandwidth value inserted in the SENDER_TSPEC and FLOWSPEC
objects MUST be ignored upon receipt and SHOULD be set to zero objects MUST be ignored upon receipt and SHOULD be set to zero
when sent. when sent.
Additionally, ingress/egress nodes that need to communicate their Additionally, ingress/egress nodes that need to communicate their
respective link local capabilities may include a LINK_CAPABILITY respective link local capabilities may include a LINK_CAPABILITY
object in the Notify message. object in the Notify message.
The receiver of a Notify message may identify whether it is part of 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 Call management or reporting an error by the presence or absence of
the SESSION ATTRIUBTE object in the <notify session list>. Full the SESSION_ATTRIBUTE object in the <notify session list>. Full
clarity, however, may be achieved by inspection of the new Call clarity, however, may be achieved by inspection of the new Call
Management (C) bit in the ADMIN STATUS object. Management (C) bit in the ADMIN_STATUS object.
Note that the POLICY_DATA object may be included in the <notify Note that the POLICY_DATA object may be included in the <notify
session list> and MAY be used to identify requestor credentials, session list> and MAY be used to identify requestor credentials,
account numbers, limits, quotas, etc. This object is opaque to RSVP, account numbers, limits, quotas, etc. This object is opaque to RSVP,
which simply passes it to policy control when required. which simply passes it to policy control when required.
Message IDs MUST be used during Call setup. Message IDs MUST be used during Call setup.
6.2.1 Accepting Call Setup 6.2.1. Accepting Call Setup
A node that receives a Notify message carrying the ADMIN STATUS 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. 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 The receiver MAY perform authorization and policy according to local
requirements. requirements.
If the Call is acceptable, the receiver responds with a Notify If the Call is acceptable, the receiver responds with a Notify
message reflecting the information from the Call request with two message reflecting the information from the Call request with two
exceptions. exceptions.
- The responder removes any LINK CAPABLITY object that was received - The responder removes any LINK_CAPABLITY object that was received
and MAY insert a LINK_CAPABILITY object that describes its own and MAY insert a LINK_CAPABILITY object that describes its own
access link. access link.
- The ADMIN STATUS object is sent with only the C bit set. All other - The ADMIN_STATUS object is sent with only the C bit set. All
bits MUST be set to zero. other bits MUST be set to zero.
The responder MUST use the Message ID object to ensure reliable The responder MUST use the Message ID object to ensure reliable
delivery of the response. If no Message ID Acknowledgement is delivery of the response. If no Message ID Acknowledgement is
received after the configured number of retries, the responder SHOULD received after the configured number of retries, the responder SHOULD
continue to assume that the Call was successfully established. Call continue to assume that the Call was successfully established. Call
liveliness procedures are covered in Section 6.7. liveliness procedures are covered in Section 6.7.
Papadimitriou and Farrel January 2007 6.2.2. Call Setup Failure and Rejection
6.2.2 Call Setup Failure and Rejection
Call setup may fail or be rejected. Call setup may fail or be rejected.
If the Notify message can not be delivered, no Message ID If the Notify message can not be delivered, no Message ID
acknowledgement will be received by the sender. In the event that the acknowledgement will be received by the sender. In the event that
sender has retransmitted the Notify message a configurable number of the sender has retransmitted the Notify message a configurable number
times without receiving a Message ID Acknowledgement (as described in of times without receiving a Message ID Acknowledgement (as described
[RFC2961]), the initiator SHOULD declare the Call failed and SHOULD in [RFC2961]), the initiator SHOULD declare the Call failed and
send a Call teardown request (see Section 6.6). SHOULD send a Call teardown request (see Section 6.6).
It is also possible that a Message ID Acknowledgement is received but It is also possible that a Message ID Acknowledgement is received but
no Call response Notify message is received. In this case, the no Call response Notify message is received. In this case, the
initiator MAY re-send the Call setup request a configurable number of initiator MAY re-send the Call setup request a configurable number of
times (see Section 6.7) before declaring that the Call has failed. At times (see Section 6.7) before declaring that the Call has failed.
this point the initiator MUST send a Call teardown request (see At this point, the initiator MUST send a Call teardown request (see
Section 6.6). Section 6.6).
If the Notify message cannot be parsed or is in error it MAY be 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 responded to with a Notify message carrying the error code 13
("Unknown object class") or 14 ("Unknown object C-Type") if ("Unknown object class") or 14 ("Unknown object C-Type") if
appropriate to the error detected. appropriate to the error detected.
The Call setup MAY be rejected by the receiver because of security, The Call setup MAY be rejected by the receiver because of security,
authorization or policy reasons. Suitable error codes already exist authorization, or policy reasons. Suitable error codes already exist
[RFC2205] and can be used in the ERROR SPEC object included in the [RFC2205] and can be used in the ERROR_SPEC object included in the
Notify message sent in response. Notify message sent in response.
Error response Notify messages SHOULD also use the Message ID object Error response Notify messages SHOULD also use the Message ID object
to achieve reliable delivery. No action should be taken on the to achieve reliable delivery. No action should be taken on the
failure to receive a Message ID Acknowledgement after the configured failure to receive a Message ID Acknowledgement after the configured
number of retries. number of retries.
6.3 Adding a Connections to a Call 6.3. Adding a Connections to a Call
Once a Call has been established, LSPs can be added to the 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 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 has the same Call ID value in the SESSION object belongs to the same
Call, and the Notify message used to establish the Call carried the Call, and the Notify message used to establish the Call carried the
same Call ID in its SESSION object. same Call ID in its SESSION object.
There will be no confusion between LSPs that are associated with a 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 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, and MUST NOT to zero for LSPs that are not associated with a Call, and MUST NOT be
be equal to zero for a valid Call ID. equal to zero for a valid Call ID.
LSPs for different Calls can be distinguished because the Call ID is LSPs for different Calls can be distinguished because the Call ID is
unique within the context of the source address (in the SENDER unique within the context of the source address (in the
TEMPLATE object) and the destination address (in the SESSION object). SENDER_TEMPLATE object) and the destination address (in the SESSION
object).
Papadimitriou and Farrel January 2007
Ingress and egress nodes MAY group together LSPs associated with the Ingress and egress nodes MAY group together LSPs associated with the
same Call and process them as a group according to implementation same Call and process them as a group according to implementation
requirements. Transit nodes need not be aware of the association of requirements. Transit nodes need not be aware of the association of
multiple LSPs with the same Call. multiple LSPs with the same Call.
The ingress node MAY choose to set the "Session Name" of an LSP to The ingress node MAY choose to set the "Session Name" of an LSP to
match the long Call ID of the associated Call. match the long Call ID of the associated Call.
The C bit of the ADMIN STATUS object MUST NOT be set on LSP messages The C bit of the ADMIN_STATUS object MUST NOT be set on LSP messages
including on Notify messages that pertain to the LSP and MUST be including on Notify messages that pertain to the LSP and MUST be
ignored. ignored.
6.3.1 Adding a Reverse Direction LSP to a Call 6.3.1. Adding a Reverse Direction LSP to a Call
Note that once a Call has been established it is symmetric. That is, Note that once a Call has been established, it is symmetric. That
either end of the Call may add LSPs to the Call. is, either end of the Call may add LSPs to the Call.
Special care is needed when managing LSPs in the reverse direction Special care is needed when managing LSPs in the reverse direction
since the addresses in the SESSION and SENDER TEMPLATE are reversed. 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 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 ingress-egress address pair, it may safely be used to associate the
LSP with the Call. LSP with the Call.
Note that since Calls are defined here to be symmetrical, the issue Note that since Calls are defined here to be symmetrical, the issue
of potential Call ID collision arises. This is discussed in Section of potential Call ID collision arises. This is discussed in Section
6.5. 6.5.
6.4 Call-Free Connection Setup 6.4. Call-Free Connection Setup
It continues to be possible to set up LSPs as per [RFC3473] without 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 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 object is set to zero, there is no associated Call and the Session
Name field in the SESSION ATTRIBUTE object MUST be interpreted simply Name field in the SESSION_ATTRIBUTE object MUST be interpreted simply
as the name of the session (see [RFC3209]). as the name of the session (see [RFC3209]).
The C bit of the ADMIN STATUS object MUST NOT be set on messages for The C bit of the ADMIN_STATUS object MUST NOT be set on messages for
LSP control, including on Notify messages that pertain to LSPs, and LSP control, including on Notify messages that pertain to LSPs, and
MUST be ignored when received on such messages. MUST be ignored when received on such messages.
6.5 Call Collision 6.5. Call Collision
Since Calls are symmetrical, it is possible that both ends of a Call Since Calls are symmetrical, it is possible that both ends of a Call
will attempt to establish Calls with the same long Call IDs at the will attempt to establish Calls with the same long Call IDs at the
same time. This is only an issue if the source and destination same time. This is only an issue if the source and destination
address pairs match. This situation can be avoided by applying some address pairs match. This situation can be avoided by applying some
rules to the contents of the long Call ID, but such mechanisms are rules to the contents of the long Call ID, but such mechanisms are
outside the scope of this document. outside the scope of this document.
If a node that has sent a Call setup request and has not yet received 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 a response itself receives a Call setup request with the same long
Papadimitriou and Farrel January 2007
Call ID and matching source/destination addresses, it SHOULD process Call ID and matching source/destination addresses, it SHOULD process
as follows. as follows:
- If its source address is numerically greater than the remote - If its source address is numerically greater than the remote
source address, it MUST discard the received message and continue source address, it MUST discard the received message and continue
to wait for a response to its setup request. to wait for a response to its setup request.
- If its source address is numerically smaller than the remote - If its source address is numerically smaller than the remote
source address, it MUST discard state associated with the Call source address, it MUST discard state associated with the Call
setup that it initiated, and MUST respond to the received Call setup that it initiated, and MUST respond to the received Call
setup. setup.
If a node receives a Call setup request carrying an address pair and If a node receives a Call setup request carrying an address pair and
long Call ID that match an existing Call, the node MUST return an long Call ID that match an existing Call, the node MUST return an
error message (Notify message) with the new Error Code "Call error message (Notify message) with the new Error Code "Call
Management" and the new Error Value "Duplicate Call" in response to Management" and the new Error Value "Duplicate Call" in response to
the new Call request, and MUST NOT make any changes to the existing the new Call request, and MUST NOT make any changes to the existing
Call. Call.
A further possibility for contention arises when short Call IDs are A further possibility for contention arises when short Call IDs are
assigned by a pair of nodes for two distinct Calls that are set up assigned by a pair of nodes for two distinct Calls that are set up
simultaneously using different long Call IDs. In this event a node simultaneously using different long Call IDs. In this event, a node
receives a Call setup request carrying a short Call ID that matches receives a Call setup request carrying a short Call ID that matches
one that it previously sent for the same address pair. The following one that it previously sent for the same address pair. The following
processing MUST be followed. processing MUST be followed:
- If the receiver's source address is numerically greater than the - If the receiver's source address is numerically greater than the
remote source address, the receiver returns an error (Notify remote source address, the receiver returns an error (Notify
message) with the new Error Code "Call Management" and the new message) with the new Error Code "Call Management" and the new
Error Value "Call ID Contention". Error Value "Call ID Contention".
- If the receiver's source address is numerically less than the - If the receiver's source address is numerically less than the
remote source address, the receiver accepts and processes the Call remote source address, the receiver accepts and processes the Call
request. It will receive an error message sent as described above, request. It will receive an error message sent as described
and at that point it selects a new short Call ID and re-sends the above, and at that point, it selects a new short Call ID and re-
Call setup request. sends the Call setup request.
6.6 Call/Connection Teardown 6.6. Call/Connection Teardown
As with Call/Connection setup, there are several cases to consider. As with Call/Connection setup, there are several cases to consider.
- Removal of a Connection from a Call - Removal of a Connection from a Call
- Removal of the last Connection from a Call - Removal of the last Connection from a Call
- Teardown of an "empty" Call - Teardown of an "empty" Call
The case of tearing down an LSP that is not associated with a 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 does not need to be examined as it follows exactly the procedures
described in [RFC3473]. described in [RFC3473].
Papadimitriou and Farrel January 2007 6.6.1. Removal of a Connection from a Call
6.6.1 Removal of a Connection from a Call
An LSP that is associated with a Call may be deleted using the An LSP that is associated with a Call may be deleted using the
standard procedures described in [RFC3473]. No special procedures are standard procedures described in [RFC3473]. No special procedures
required. are required.
Note that it is not possible to remove an LSP from a Call without 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 deleting the LSP. It is not valid to change the short Call ID from
non-zero to zero since this involves a change to the SESSION object, non-zero to zero since this involves a change to the SESSION object,
which is not allowed. which is not allowed.
6.6.2 Removal of the Last Connection from a Call 6.6.2. Removal of the Last Connection from a Call
When the last LSP associated with a Call is deleted, the question 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 arises as to what happens to the Call. Since a Call may exist
independently of Connections, it is not always acceptable to say that independently of Connections, it is not always acceptable to say that
the removal of the last LSP from a Call removes the Call. the removal of the last LSP from a Call removes the Call.
The removal of the last LSP does not remove the Call and the 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 procedures described in the next Section MUST be used to delete the
Call. Call.
6.6.3 Teardown of an "Empty" Call 6.6.3. Teardown of an "Empty" Call
When all LSPs have been removed from a Call, the Call may be torn When all LSPs have been removed from a Call, the Call may be torn
down or left for use by future LSPs. down or left for use by future LSPs.
Deletion of Calls is achieved by sending a Notify message just as for Deletion of 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 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 on the teardown request and the D and C bits on the teardown
response. Other bits MUST be set to zero. response. Other bits MUST be set to zero.
When a Notify message is sent for deleting a Call and the initiator When a Notify message is sent for deleting a Call and the initiator
does not receive the corresponding reflected Notify message (or does not receive the corresponding reflected Notify message (or
possibly even the Message ID Ack), the initiator MAY retry the possibly even the Message ID Ack), the initiator MAY retry the
deletion request using the same retry procedures as used during Call deletion request using the same retry procedures as used during Call
establishment. If no response is received after full retry, the node establishment. If no response is received after full retry, the node
deleting the Call MAY declare the Call deleted, but under such deleting the Call MAY declare the Call deleted, but under such
circumstances the node SHOULD avoid re-using the long or short Call circumstances the node SHOULD avoid re-using the long or short Call
IDs for at least five times the Notify refresh period. IDs for at least five times the Notify refresh period.
6.6.4 Attempted Teardown of a Call with Existing Connections 6.6.4. Attempted Teardown of a Call with Existing Connections
If a Notify request with the D bit of the ADMIN STATUS object set is 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 received for a Call for which LSPs still exist, the request MUST be
rejected with the Error Code "Call Management" and Error Value rejected with the Error Code "Call Management" and Error Value
"Connections Still Exist". The state of the Call MUST NOT be changed. "Connections Still Exist". The state of the Call MUST NOT be
changed.
Papadimitriou and Farrel January 2007
6.6.5 Teardown of a Call from the Egress 6.6.5. Teardown of a Call from the Egress
Since Calls are symmetric they may be torn down from the ingress or Since Calls are symmetric, they may be torn down from the ingress or
egress. egress.
When the Call is "empty" (has no associated LSPs) it may be deleted When the Call is "empty" (has no associated LSPs), it may be deleted
by the egress sending a Notify message just as described above. by the egress sending a Notify message just as described above.
Note that there is a possibility that both ends of a Call initiate Note that there is a possibility that both ends of a Call initiate
Call deletion at the same time. In this case, the Notify message Call deletion at the same time. In this case, the Notify message
acting as teardown request MAY be interpreted by its recipient as a acting as teardown request MAY be interpreted by its recipient as a
teardown response. But since the Notify messages acting as teardown teardown response. But since the Notify messages acting as teardown
requests carry the R bit in the ADMIN STATUS object, they MUST be requests carry the R bit in the ADMIN_STATUS object, they MUST be
responded to anyway. If a teardown request Notify message is received responded to anyway. If a teardown request Notify message is
for an unknown Call ID, it is, nevertheless, responded to in the received for an unknown Call ID, it is, nevertheless, responded to in
affirmative. the affirmative.
6.7 Control Plane Survivability 6.7. Control Plane Survivability
Delivery of Notify messages is secured using message ID Delivery of Notify messages is secured using Message ID
acknowledgements as described in previous sections. Acknowledgements as described in previous sections.
Notify messages provide end-to-end communication that does not rely Notify messages provide end-to-end communication that does not rely
on constant paths through the network. Notify messages are routed on constant paths through the network. Notify messages are routed
according to IGP routing information. No consideration is, therefore, according to IGP routing information. No consideration is,
required for network resilience (for example, make-before-break, therefore, required for network resilience (for example, make-
protection, fast re-route), although end-to-end resilience is of before-break, protection, fast re-route), although end-to-end
interest for node restart and completely disjoint networks. resilience is of interest for node restart and completely disjoint
networks.
Periodic Notify messages SHOULD be sent by the initiator and Periodic Notify messages SHOULD be sent by the initiator and
terminator of the Call to keep the Call alive and to handle ingress terminator of the Call to keep the Call alive and to handle ingress
or egress node restart. The time period for these retransmissions is or egress node restart. The time period for these retransmissions is
a local matter, but it is RECOMMENDED that this period should be a local matter, but it is RECOMMENDED that this period should be
twice the shortest refresh period of any LSP associated with the twice the shortest refresh period of any LSP associated with the
Call. When there are no LSPs associated with a Call, an LSR is Call. When there are no LSPs associated with a Call, an LSR is
RECOMMENDED to use a refresh period of no less than one minute. The RECOMMENDED to use a refresh period of no less than one minute. The
Notify messages are identical to those sent as if establishing the Notify messages are identical to those sent as if establishing the
Call for the first time, except for the LINK_CAPABILITY object, which 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., may have changed since the Call was first established, due to, e.g.,
the establishment of Connections, link failures, or the addition of the establishment of Connections, link failures, or the addition of
new component links. The current link information is useful for the new component links. The current link information is useful for the
establishment of subsequent Connections. A node that receives a establishment of subsequent Connections. A node that receives a
refresh Notify message carrying the R bit in the ADMIN STATUS object refresh Notify message carrying the R bit in the ADMIN_STATUS object
MUST respond with a Notify response. A node that receives a refresh MUST respond with a Notify response. A node that receives a refresh
Notify message (response or request) MAY reset its timer - thus, in Notify message (response or request) MAY reset its timer - thus, in
normal processing, Notify refreshes involve a single exchange once normal processing, Notify refreshes involve a single exchange once
per time period. per time period.
Papadimitriou and Farrel January 2007
A node (sender or receiver) that is unsure of the status of a Call A node (sender or receiver) that is unsure of the status of a Call
MAY immediately send a Notify message as if establishing the Call for MAY immediately send a Notify message as if establishing the Call for
the first time. the first time.
Failure to receive a refresh Notify request has no specific meaning. Failure to receive a refresh Notify request has no specific meaning.
A node that fails to receive a refresh Notify request MAY send its A node that fails to receive a refresh Notify request MAY send its
own refresh Notify request to establish the status of the Call. If a own refresh Notify request to establish the status of the Call. If a
node receives no response to a refresh Notify request (including no node receives no response to a refresh Notify request (including no
Message ID Acknowledgement) a node MAY assume that the remote node is Message ID Acknowledgement), a node MAY assume that the remote node
unreachable or unavailable. It is a local policy matter whether this is unreachable or unavailable. It is a local policy matter whether
causes the local node to teardown associated LSPs and delete the this causes the local node to teardown associated LSPs and delete the
Call. Call.
In the event that an edge node restarts without preserved state, it In the event that an edge node restarts without preserved state, it
MAY relearn LSP state from adjacent nodes and Call state from remote 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 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 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 not recognized, the receiver is RECOMMENDED to assume that the Call
establishment is delayed and ignore the received message. If the Call establishment is delayed and ignore the received message. If the
setup never materializes, the failure by the restarting node to Call setup never materializes, the failure by the restarting node to
refresh state will cause the LSPs to be torn down. Optionally, the 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 receiver of such an LSP message for an unknown Call ID may return an
error (PathErr or ResvErr message) with the error code "Call error (PathErr or ResvErr message) with the error code "Call
Management" and Error Value "Unknown Call ID". Management" and Error Value "Unknown Call ID".
7. Applicability of Call and Connection Procedures 7. Applicability of Call and Connection Procedures
This section considers the applicability of the different Call This section considers the applicability of the different Call
establishment procedures at the NNI and UNI reference points. This establishment procedures at the NNI and UNI reference points. This
section is informative and is not intended to prescribe or prevent section is informative and is not intended to prescribe or prevent
other options. other options.
7.1 Network-initiated Calls 7.1. Network-Initiated Calls
Since the link properties and other traffic-engineering attributes Since the link properties and other traffic-engineering attributes
are likely known through the IGP, the LINK_CAPABILITY object is not are likely known through the IGP, the LINK_CAPABILITY object is not
usually required. usually required.
In multi-domain networks, it is possible that access link properties In multi-domain networks, it is possible that access link properties
and other traffic-engineering attributes are not known since the and other traffic-engineering attributes are not known since the
domains do not share this sort of information. In this case, the Call domains do not share this sort of information. In this case, the
setup mechanism may include the LINK_CAPABILITY object. Call setup mechanism may include the LINK_CAPABILITY object.
7.2 User-initiated Calls 7.2. User-Initiated Calls
It is possible that the access link properties and other traffic- It is possible that the access link properties and other traffic-
engineering attributes are not shared across the core network. In engineering attributes are not shared across the core network. In
this case, the Call setup mechanism may include the LINK_CAPABILITY this case, the Call setup mechanism may include the LINK_CAPABILITY
object. object.
Papadimitriou and Farrel January 2007
Further, the first node within the network may be responsible for Further, the first node within the network may be responsible for
managing the Call. In this case, the Notify message that is used to managing the Call. In this case, the Notify message that is used to
set up the Call is addressed by the user network edge node to the set up the Call is addressed by the user network edge node to the
first node of the core network. Moreover, neither the long Call ID 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 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 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 passed to the first core node, which is responsible for generating
the long and short Call IDs before dispatching the message to the the long and short Call IDs before dispatching the message to the
remote Call end point (which is known from the SESSION object). remote Call end point (which is known from the SESSION object).
Further, when used in an overlay context, the first core node is Further, when used in an overlay context, the first core node is
allowed (see [RFC4208]) to replace the Session Name assigned by the allowed (see [RFC4208]) to replace the Session Name assigned by the
ingress node and passed in the Path message. In the case of Call ingress node and passed in the Path message. In the case of Call
management, the first network node: management, the first core node:
1) MAY insert a long Call ID in the Session Name of a Path message
2) MUST replace the Session Name with that originally issued by the
user edge node when it returns the Resv message to the ingress node.
7.3 External Call Managers 1) MAY insert a long Call ID in the Session Name of a Path
message.
2) MUST replace the Session Name with that originally issued by
the user edge node when it returns the Resv message to the
ingress node.
7.3. External Call Managers
Third party Call management agents may be used to apply policy and Third party Call management agents may be used to apply policy and
authorization at a point that is neither the initiator nor terminator authorization at a point that is neither the initiator nor terminator
of the Call. The previous example is a particular case of this, but of the Call. The previous example is a particular case of this, but
the process and procedures are identical. the process and procedures are identical.
7.3.1 Call Segments 7.3.1. Call Segments
Call Segments exist between a set of default and configured External Call Segments exist between a set of default and configured External
Call Managers along a path between the ingress and egress nodes, and Call Managers along a path between the ingress and egress nodes, and
use the protocols described in this document. use the protocols described in this document.
The techniques that are used by a given service provider to identify The techniques that are used by a given service provider to identify
which External Call Managers within its network should process a which External Call Managers within its network should process a
given Call are beyond the scope of this document. given Call are beyond the scope of this document.
An External Call Manager uses normal IP routing to route the Notify An External Call Manager uses normal IP routing to route the Notify
message to the next External Call Manager. Notify messages (requests message to the next External Call Manager. Notify messages (requests
and responses) are therefore encapsulated in IP packets that identify and responses) are therefore encapsulated in IP packets that identify
the sending and receiving External Call Managers, but the addresses the sending and receiving External Call Managers, but the addresses
used to identify the Call (the Sender Address in the SENDER TEMPLATE used to identify the Call (the Sender Address in the SENDER_TEMPLATE
object and the Tunnel Endpoint Address in the SESSION object) object and the Tunnel Endpoint Address in the SESSION object)
continue to identify the endpoints of the Call. continue to identify the endpoints of the Call.
8. Non-support of Call ID 8. Non-Support of Call ID
It is important that the procedures described above operate as It is important that the procedures described above operate as
seamlessly as possible with legacy nodes that do not support the seamlessly as possible with legacy nodes that do not support the
extensions described. extensions described.
Papadimitriou and Farrel January 2007
Clearly, there is no need to consider the case where the Call Clearly, there is no need to consider the case where the Call
initiator does not support Call setup initiation. initiator does not support Call setup initiation.
8.1 Non-Support by External Call Managers 8.1. Non-Support by External Call Managers
It is unlikely that a Call initiator will be configured to send Call It is unlikely that a Call initiator will be configured to send Call
establishment Notify requests to an external Call manager, including establishment Notify requests to an external Call manager, including
the first network node, if that node does not support Call setup. the first core node, if that node does not support Call setup.
A node that receives an unexpected Call setup request will fall into A node that receives an unexpected Call setup request will fall into
one of the following categories. one of the following categories.
- Node does not support RSVP. The message will fail to be delivered - Node does not support RSVP. The message will fail to be delivered
or responded. No Message ID Acknowledgement will be sent. The or responded to. No Message ID Acknowledgement will be sent. The
initiator will retry and then give up. initiator will retry and then give up.
- Node supports RSVP or RSVP-TE but not GMPLS. The message will be - Node supports RSVP or RSVP-TE but not GMPLS. The message will be
delivered but not understood. It will be discarded. No Message ID delivered but not understood. It will be discarded. No Message
Acknowledgement will be sent. The initiator will retry and then ID Acknowledgement will be sent. The initiator will retry and
give up. then give up.
- Node supports GMPLS but not Call management. The message will be - Node supports GMPLS but not Call management. The message will be
delivered, but parsing will fail because of the presence of the delivered, but parsing will fail because of the presence of the
SESSION ATTRIBUTE object. A Message ID Acknowledgement may be sent SESSION_ATTRIBUTE object. A Message ID Acknowledgement may be
before the parse fails. When the parse fails the Notify message sent before the parse fails. When the parse fails, the Notify
may be discarded in which case the initiator will retry and then message may be discarded in which case the initiator will retry
give up, alternatively a parse error may be generated and returned and then give up; alternatively, a parse error may be generated
in a Notify message which will indicate to the initiator that Call and returned in a Notify message which will indicate to the
management is not supported. initiator that Call management is not supported.
8.2 Non-Support by Transit Node 8.2. Non-Support by Transit Node
Transit nodes SHOULD NOT examine Notify messages that are not Transit nodes SHOULD NOT examine Notify messages that are not
addressed to them. However, they will see short Call IDs in all addressed to them. However, they will see short Call IDs in all
messages for all LSPs associated with Calls. messages for all LSPs associated with Calls.
Previous specifications state that these fields SHOULD be ignored on Previous specifications state that these fields SHOULD be ignored on
receipt and MUST be transmitted as zero. This might interpreted by receipt and MUST be transmitted as zero. This might be interpreted
some implementations as meaning that the fields should be zeroed by some implementations as meaning that the fields should be zeroed
before the objects are forwarded. If this happens, LSP setup will not before the objects are forwarded. If this happens, LSP setup will
be possible. If either of the fields is zeroed either on the Path or not be possible. If either of the fields is zeroed either on the
the Resv message, the Resv message will reach the initiator with the Path or the Resv message, the Resv message will reach the initiator
field set to zero - this is indication to the initiator that some with the field set to zero - this is an indication to the initiator
node in the network is preventing Call management. Use of Explicit that some node in the network is preventing Call management. Use of
Routes may help to mitigate this issue by avoiding such nodes. Explicit Routes may help to mitigate this issue by avoiding such
Ultimately, however, it may be necessary to upgrade the offending nodes. Ultimately, however, it may be necessary to upgrade the
nodes to handle these protocol extensions. offending nodes to handle these protocol extensions.
Papadimitriou and Farrel January 2007
8.3 Non-Support by Egress Node 8.3. Non-Support by Egress Node
It is unlikely that an attempt will be made to set up a Call to It is unlikely that an attempt will be made to set up a Call to a
remote node that does not support Calls. remote node that does not support Calls.
If the egress node does not support Call management through the If the egress node does not support Call management through the
Notify message it will react (as described in Section 8.1) in the Notify message, it will react (as described in Section 8.1) in the
same way as an External Call Manager. same way as an External Call Manager.
9. Security Considerations 9. Security Considerations
Please refer to each of the documents referenced in the following Please refer to each of the documents referenced in the following
sections for a description of the security considerations applicable sections for a description of the security considerations applicable
to the features that they provide. to the features that they provide.
9.1 Call and Connection Security Considerations 9.1. Call and Connection Security Considerations
Call setup is vulnerable to attacks both of spoofing and denial of Call setup is vulnerable to attacks both of spoofing and denial of
service. Since Call setup uses Notify messages, the process can be service. Since Call setup uses Notify messages, the process can be
protected by the use of the Integrity object to secure those messages protected by the use of the INTEGRITY object to secure those messages
as described in [RFC2205] and [RFC3473]. Deployments where as described in [RFC2205] and [RFC3473]. Deployments where security
security is a concern SHOULD use this mechanism. is a concern SHOULD use this mechanism.
Implementations and deployments MAY additionally protect the Implementations and deployments MAY additionally protect the Call
Call setup exchange using end-to-end security mechanisms such as setup exchange using end-to-end security mechanisms such as those
those provided by IPsec (see [RFC4302] and [RFC4303]), or using RSVP provided by IPsec (see [RFC4302] and [RFC4303]), or using RSVP
security [RFC2747]. security [RFC2747].
Note, additionally, that the process of independent Call Note, additionally, that it would be desirable to use the process of
establishment, where the Call is set up separately from the LSPs, may independent Call establishment, where the Call is set up separately
be used to apply an extra level of authentication and policy for the from the LSPs, to apply an extra level of authentication and policy
end-to-end LSPs above that which is available with Call-less, for the end-to-end LSPs above that which is available with Call-less,
hop-by-hop LSP setup. hop-by-hop LSP setup. However doing so will require additional work
to set up security associations between the peer and the call manager
that meet the requirements of [RFC4107]. The mechanism described in
this document is expected to meet this use case when combined with
this additional work. Application of this mechanism to the
authentication and policy use case prior to standardization of a
security solution is inappropriate and outside the current
applicability of the mechanism.
The frequency of Call establishment is application dependent and hard The frequency of Call establishment is application dependent and hard
to generalize. Key exchange for Call-related message exchanges is to generalize. Key exchange for Call-related message exchanges is
therefore something that should be configured or arranged dynamically therefore something that should be configured or arranged dynamically
in different deployments according to the advice in [RFC4107]. Note in different deployments according to the advice in [RFC4107]. Note
that the remote RSVP-TE signaling relationship between Call endpoints that the remote RSVP-TE signaling relationship between Call endpoints
is no different from the signaling relationship between LSRs that is no different from the signaling relationship between LSRs that
establish an LSP. That is, the LSRs are not necessarily IP-adjacent establish an LSP. That is, the LSRs are not necessarily IP-adjacent
in the control plane in either case. Thus key exchange should be in the control plane in either case. Thus, key exchange should be
regarded as a remote procedure, not a single hop procedure. There are regarded as a remote procedure, not a single hop procedure. There
several procedures for automatic remote exchange of keys, and IKEv2 are several procedures for automatic remote exchange of keys, and
[RFC4306] is particularly suggested in [RFC3473]. IKEv2 [RFC4306] is particularly suggested in [RFC3473].
Papadimitriou and Farrel January 2007
10. IANA Considerations 10. IANA Considerations
10.1 RSVP Objects 10.1. RSVP Objects
A new RSVP object is introduced. IANA is requested to make an A new RSVP object is introduced. IANA has made an assignment from
assignment from the "RSVP Parameters" registry using the sub-registry the "RSVP Parameters" registry using the sub-registry "Class Names,
"Class Names, Class Numbers, and Class Types". Class Numbers, and Class Types".
o LINK_CAPABILITY object o LINK_CAPABILITY object
Class-Num = TBA (form 10bbbbbb - suggested value 132) Class-Num = 133 (form 10bbbbbb)
The Class Number is selected so that nodes not recognizing The Class Number is selected so that nodes not recognizing this
this object drop it silently. That is, the top bit is set object drop it silently. That is, the top bit is set and the next
and the next bit is cleared. bit is cleared.
C-Type = 1 (TE Link Capabilities) C-Type = 1 (TE Link Capabilities)
The LINK_CAPABILITY object is only defined for inclusion on Notify The LINK_CAPABILITY object is only defined for inclusion on Notify
messages. messages.
Refer to Section 5.3 of this document. Refer to Section 5.3 of this document.
IANA is requested to maintain a list of subobjects that may be IANA maintains a list of subobjects that may be carried in this
carried in this object. This list should be maintained in the object. This list is maintained in the registry entry for the
registry entry for the LINK_CAPABILITY object as is common LINK_CAPABILITY object as is common practice for the subobjects of
practice for the subobjects of other RSVP objects. For each other RSVP objects. For each subobject, IANA lists:
subobject, IANA should list:
- subobject type number - subobject type number
- subobject name - subobject name
- reference indicating where subobject is defined. - reference indicating where subobject is defined.
The initial list of subobjects is provided in Section 5.3 of this The initial list of subobjects is provided in Section 5.3 of this
document. document.
10.2 RSVP Error Codes and Error Values 10.2. RSVP Error Codes and Error Values
A new RSVP Error Code and new Error Values are introduced. IANA is A new RSVP Error Code and new Error Values are introduced. IANA has
requested to make assignments from the "RSVP Parameters" registry made assignments from the "RSVP Parameters" registry using the sub-
using the sub-registry "Error Codes and Globally-Defined Error registry "Error Codes and Globally-Defined Error Value Sub-Codes".
Value Sub-Codes".
o Error Codes: o Error Codes:
- Call Management (value TBA - suggested value 32) - Call Management (value 32)
o Error Values: o Error Values:
- Call Management/Call ID Contention (value TBA- suggested 1) - Call Management/Call ID Contention (value 1)
- Call Management/Connections still Exist (value TBA- suggested 2) - Call Management/Connections Still Exist (value 2)
- Call Management/Unknown Call ID (value TBA- suggested 3) - Call Management/Unknown Call ID (value 3)
- Call Management/Duplicate Call (value TBA- suggested 4) - Call Management/Duplicate Call (value 4)
Papadimitriou and Farrel January 2007
10.3 RSVP ADMIN_STATUS object Bits 10.3. RSVP ADMIN_STATUS Object Bits
[GMPLS-E2E] requests IANA to manage the bits of the RSVP ADMIN_STATUS [GMPLS-E2E] requested that IANA manage the bits of the RSVP
object. A new "Administrative Status Information Flags" sub-registry ADMIN_STATUS object. A new "Administrative Status Information Flags"
of the "GMPLS Signaling Parameters" registry is created. sub-registry of the "GMPLS Signaling Parameters" registry was
created.
This document defines one new bit, the C bit, to be tracked in that This document defines one new bit, the C bit, to be tracked in that
sub-registry. Bit number 28 is suggested. See Section 5.5 of this sub-registry. Bit number 28 has been assigned. See Section 5.5 of
document. this document.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank George Swallow, Yakov Rekhter, The authors would like to thank George Swallow, Yakov Rekhter, Lou
Lou Berger, Jerry Ash and Kireeti Kompella for their very useful Berger, Jerry Ash, and Kireeti Kompella for their very useful input
input to, and comments on, an earlier revision of this document. to, and comments on, an earlier revision of this document.
Thanks to Lyndon Ong and Ben Mack-Crane for lengthy discussions Thanks to Lyndon Ong and Ben Mack-Crane for lengthy discussions
during and after working group last call, and to Deborah Brungard for during and after working group last call, and to Deborah Brungard for
a final, detailed review. a final, detailed review.
Thanks to Suresh Krishnan for the GenArt review, and to Magnus Thanks to Suresh Krishnan for the GenArt review, and to Magnus
Nystrom for discussions about security. Nystrom for discussions about security.
Useful comments were received during IESG review from Brian Useful comments were received during IESG review from Brian
Carpenter, Lars Eggert, Ted Hardie, Russ Housley, Carpenter, Lars Eggert, Ted Hardie, Sam Hartman, and Russ Housley.
12. References 12. References
12.1 Normative References 12.1. Normative References
[GMPLS-E2E] Lang, J.P., Rekhter, Y., and D. Papadimitriou, "RSVP-
TE Extensions in support of End-to-End Generalized
Multi-Protocol Label Switching (GMPLS)-based Recovery,"
draft-ietf-ccamp-gmpls-recovery-e2e-signaling, work in
progress.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [GMPLS-E2E] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Requirement Levels," BCP 14, RFC 2119, March 1997. Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, May 2007.
[RFC2205] R. Braden et al., "Resource ReSerVation Protocol [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
(RSVP)- Version 1 Functional Specification," Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC 2205, September 1997.
[RFC2747] Baker, F., Lindell, B. and M. Talwar, "RSVP [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and
Cryptographic Authentication", RFC 2747, January S. Jamin, "Resource ReSerVation Protocol (RSVP) --
2000. Version 1 Functional Specification", RFC 2205, September
1997.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
F. and S. Molendini, "RSVP Refresh Overhead Cryptographic Authentication", RFC 2747, January 2000.
Reduction Extensions", RFC 2961, April 2001.
Papadimitriou and Farrel January 2007 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001.
[RFC3209] D. Awduche et al., "RSVP-TE: Extensions to RSVP for [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
LSP Tunnels," RFC 3209, December 2001. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3471] L. Berger (Editor) et al., "Generalized MPLS - [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Signaling Functional Description," RFC 3471, January Switching (GMPLS) Signaling Functional Description", RFC
2003. 3471, January 2003.
[RFC3473] L. Berger (Editor) et al., "Generalized MPLS Signaling [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
- RSVP-TE Extensions," RFC 3473, January 2003. Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
Links in Resource ReSerVation Protocol - Traffic in Resource ReSerVation Protocol - Traffic Engineering
Engineering (RSVP-TE)," RFC 3477, January 2003. (RSVP-TE)", RFC 3477, January 2003.
[RFC3945] E. Mannie, Ed., "Generalized Multi-Protocol Label [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October Switching (GMPLS) Architecture", RFC 3945, October 2004.
2004.
[RFC4201] Kompella K., Rekhter Y., and L. Berger, "Link Bundling [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering," RFC 4201, October 2005. in MPLS Traffic Engineering (TE)", RFC 4201, October
2005.
[RFC4202] Kompella, K. and Y. Rekhter (Editors) et al., "Routing [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized MPLS," RFC 4202, Extensions in Support of Generalized Multi-Protocol Label
October 2005. Switching (GMPLS)", RFC 4202, October 2005.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter, Y. [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) "Generalized Multiprotocol Label Switching (GMPLS) User-
User-Network Interface (UNI): Resource ReserVation Network Interface (UNI): Resource ReserVation Protocol-
Protocol-Traffic Engineering (RSVP-TE) Support for the Traffic Engineering (RSVP-TE) Support for the Overlay
Overlay Model", RFC 4208, October 2005. Model", RFC 4208, October 2005.
[RFC4302] Kent, S., "IP Authentication Header," RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
December 2005. 2005.
[RFC4303] Kent, S., "IP Encapsulating Payload (ESP)," RFC 4303, [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
December 2005. 4303, December 2005.
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005. Protocol", RFC 4306, December 2005.
[RFC4426] Lang, J.P., and B. Rajagopalan (Editors) et al., [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D.
"Generalized MPLS Recovery Functional Papadimitriou, Ed., "Generalized Multi-Protocol Label
Specification," RFC 4426, March 2006. Switching (GMPLS) Recovery Functional Specification", RFC
4426, March 2006.
12.2 Informative References
[ASON-APPL] D. Papadimitriou et. al., "Generalized MPLS (GMPLS) 12.2. Informative References
RSVP-TE signaling usage in support of Automatically
Switched Optical Network (ASON),"
draft-ietf-ccamp-gmpls-rsvp-te-ason, work in progress.
Papadimitriou and Farrel January 2007 [ASON-APPL] Drake, J., Papadimitriou, D., Farrel, A., Brungard, D.,
Ali, Z., Ayyangar, A., Ould-Brahim, H., and D. Fedyk,
"Generalized MPLS (GMPLS) RSVP-TE Signalling in support
of Automatically Switched Optical Network (ASON), Work in
Progress, July 2005.
[RFC4107] S. Bellovin and R. Housley, "Guidelines for Cryptographic [RFC4107] Bellovin, S. and R. Housley, "Guidelines for
Key Management", BCP 107, RFC 4107, June 2005. Cryptographic Key Management", BCP 107, RFC 4107, June
2005.
[RFC4139] D. Papadimitriou, et al., "Requirements for Generalized [RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A., and L.
MPLS (GMPLS) Signaling Usage and Extensions for Ong, "Requirements for Generalized MPLS (GMPLS) Signaling
Automatically Switched Optical Network (ASON)," RFC Usage and Extensions for Automatically Switched Optical
4139, July 2005. Network (ASON)", RFC 4139, July 2005.
[STITCH] Ayyangar, A., Kompella, K., and Vasseur, JP., "Label [STITCH] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
Switched Path Stitching with Generalized MPLS Traffic "Label Switched Path Stitching with Generalized
Engineering", draft-ietf-ccamp-lsp-stitching, work in Multiprotocol Label Switching Traffic Engineering (GMPLS
progress. TE)", Work in Progress, April 2007.
For information on the availability of the following document, For information on the availability of the following document, please
please see http://www.itu.int. see http://www.itu.int.
[G.8080] ITU-T, "Architecture for the Automatically Switched [G.8080] ITU-T, "Architecture for the Automatically Switched
Optical Network (ASON)," Recommendation G.8080/ Optical Network (ASON)," Recommendation G.8080/ Y.1304,
Y.1304, November 2001 (and Revision, January 2003). November 2001 (and Revision, January 2003).
13. Contact Addresses
Dimitri Papadimitriou
Alcatel-Lucent,
Fr. Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel-lucent.be
Adrian Farrel
Old Dog Consulting
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
14. Authors' Addresses Authors' Addresses
John Drake John Drake
Boeing Satellite Systems Boeing Satellite Systems
2300 East Imperial Highway 2300 East Imperial Highway
El Segundo, CA 90245 El Segundo, CA 90245
EMail: John.E.Drake2@boeing.com EMail: John.E.Drake2@boeing.com
Deborah Brungard (AT&T) Deborah Brungard (AT&T)
Rm. D1-3C22 - 200 S. Laurel Ave. Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ 07748, USA Middletown, NJ 07748, USA
EMail: dbrungard@att.com EMail: dbrungard@att.com
Papadimitriou and Farrel January 2007
Zafar Ali (Cisco) Zafar Ali (Cisco)
100 South Main St. #200 100 South Main St. #200
Ann Arbor, MI 48104, USA Ann Arbor, MI 48104, USA
EMail: zali@cisco.com EMail: zali@cisco.com
Arthi Ayyangar (Nuova Systems) Arthi Ayyangar (Nuova Systems)
2600 San Tomas Expressway 2600 San Tomas Expressway
Santa Clara, CA 95051 Santa Clara, CA 95051
EMail: arthi@nuovasystems.com EMail: arthi@nuovasystems.com
Don Fedyk (Nortel Networks) Don Fedyk (Nortel Networks)
600 Technology Park Drive 600 Technology Park Drive
Billerica, MA, 01821, USA Billerica, MA, 01821, USA
Email: dwfedyk@nortel.com EMail: dwfedyk@nortel.com
Intellectual Property Statement Contact Addresses
Dimitri Papadimitriou
Alcatel-Lucent,
Fr. Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel-lucent.be
Adrian Farrel
Old Dog Consulting
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. 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, THE IETF TRUST 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.
Papadimitriou and Farrel January 2007
Copyright Statement
Copyright (C) The IETF Trust (2007). Acknowledgement
This document is subject to the rights, licenses and restrictions Funding for the RFC Editor function is currently provided by the
contained in BCP 78, and except as set forth therein, the authors Internet Society.
retain all their rights.
 End of changes. 220 change blocks. 
571 lines changed or deleted 528 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/