draft-ietf-ccamp-gmpls-rsvp-te-ason-03.txt   draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt 
CCAMP Working Group J. Drake (Boeing) CCAMP Working Group J. Drake (Boeing)
Internet Draft D. Papadimitriou (Alcatel) Internet Draft D. Papadimitriou (Alcatel)
Proposed Category: Standard Track A. Farrel (Old Dog Consulting) Proposed Category: Standard Track A. Farrel (Old Dog Consulting)
D. Brungard (ATT) D. Brungard (ATT)
Z. Ali (Cisco) Z. Ali (Cisco)
A. Ayyangar (Juniper) A. Ayyangar (Juniper)
H. Ould-Brahim (Nortel) H. Ould-Brahim (Nortel)
D. Fedyk (Nortel) D. Fedyk (Nortel)
Expiration Date: August 2005 February 2005 Expiration Date: January 2006 July 2005
Generalized MPLS (GMPLS) RSVP-TE Signalling Generalized MPLS (GMPLS) RSVP-TE Signalling
in support of Automatically Switched Optical Network (ASON) in support of Automatically Switched Optical Network (ASON)
draft-ietf-ccamp-gmpls-rsvp-te-ason-03.txt draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 22, 2005. This Internet-Draft will expire on January 19, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document specifies how Generalized MPLS (GMPLS) RSVP-TE This document specifies how Generalized MPLS (GMPLS) RSVP-TE
signaling may be used and extended to satisfy the requirements of the signaling may be used and extended to satisfy the requirements of the
Automatically Switched Optical Network (ASON) architecture specified Automatically Switched Optical Network (ASON) architecture specified
by the ITU-T. The requirements are in a companion document by the ITU-T. The requirements are in a companion document
D.Papadimitriou et al. - Expires August 2005 1
"Requirements for Generalized MPLS (GMPLS) Usage and Extensions for "Requirements for Generalized MPLS (GMPLS) Usage and Extensions for
Automatically Switched Optical Network (ASON)." Automatically Switched Optical Network (ASON)."
D.Papadimitriou et al. - Expires January 2006 1
In particular, this document details the mechanisms for setting up In particular, this document details the mechanisms for setting up
Soft Permanent Connections (SPC), the necessary extensions in Soft Permanent Connections (SPC), the necessary extensions in
delivering full and logical call/connection separation support, the delivering full and logical call/connection separation support, the
extended restart capabilities during control plane failures, extended extended restart capabilities during control plane failures, extended
label usage and crankback signalling capability. label usage and crankback signalling capability.
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.
skipping to change at line 108 skipping to change at line 106
6.1.3 Short Call ID Encoding .................................... 13 6.1.3 Short Call ID Encoding .................................... 13
6.2 LINK_CAPABILITY Object ...................................... 14 6.2 LINK_CAPABILITY Object ...................................... 14
6.3 Revised Message Format ...................................... 14 6.3 Revised Message Format ...................................... 14
6.3.1 Notify Message ............................................ 15 6.3.1 Notify Message ............................................ 15
6.4 ADMIN_STATUS Object ......................................... 15 6.4 ADMIN_STATUS Object ......................................... 15
7. Procedures in Support of Call and Connections ................ 16 7. Procedures in Support of Call and Connections ................ 16
7.1 Call/Connection Setup Procedures ............................ 16 7.1 Call/Connection Setup Procedures ............................ 16
7.2 Independent Call Setup ...................................... 17 7.2 Independent Call Setup ...................................... 17
7.2.1 Accepting Independent Call Setup .......................... 18 7.2.1 Accepting Independent Call Setup .......................... 18
7.2.2 Rejecting Independent Call Setup .......................... 19 7.2.2 Rejecting Independent Call Setup .......................... 19
D.Papadimitriou et al. - Expires August 2005 2
7.3 Adding a Connection to a Call ............................... 19 7.3 Adding a Connection to a Call ............................... 19
7.3.1 Adding a Reverse Direction Connection to a Call ........... 20 7.3.1 Adding a Reverse Direction Connection to a Call ........... 20
D.Papadimitriou et al. - Expires January 2006 2
7.4 Simultaneous Call/Connection Setup .......................... 20 7.4 Simultaneous Call/Connection Setup .......................... 20
7.4.1 Accepting Simultaneous Call/Connection Setup .............. 20 7.4.1 Accepting Simultaneous Call/Connection Setup .............. 20
7.4.2 Rejecting Simultaneous Call/Connection Setup .............. 21 7.4.2 Rejecting Simultaneous Call/Connection Setup .............. 21
7.5 Call-Free Connection Setup .................................. 21 7.5 Call-Free Connection Setup .................................. 21
7.6 Call Collision .............................................. 21 7.6 Call Collision .............................................. 21
7.7 Call/Connection Teardown .................................... 22 7.7 Call/Connection Teardown .................................... 22
7.7.1 Removal of a Connection from a Call ....................... 22 7.7.1 Removal of a Connection from a Call ....................... 22
7.7.2 Removal of the Last Connection from a Call ................ 23 7.7.2 Removal of the Last Connection from a Call ................ 23
7.7.3 Teardown of an "Empty" Call ............................... 23 7.7.3 Teardown of an "Empty" Call ............................... 23
7.7.4 Teardown of a Call with Existing Connections .............. 23 7.7.4 Teardown of a Call with Existing Connections .............. 23
skipping to change at line 151 skipping to change at line 149
Appendix 1. Analysis of G.7713.2 against GMPLS RSVP-TE Signaling Appendix 1. Analysis of G.7713.2 against GMPLS RSVP-TE Signaling
Requirements in Support of ASON.................................. 32 Requirements in Support of ASON.................................. 32
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
In addition, the reader is assumed to be familiar with the In addition, the reader is assumed to be familiar with the
terminology used in [RFC3471], [RFC3473] and [RFC3945]. terminology used in [RFC3471], [RFC3473], [RFC3477] and [RFC3945].
3. Introduction 3. Introduction
This document describes how GMPLS RSVP-TE signaling [RFC3473] can be This document describes how GMPLS RSVP-TE signaling [RFC3473] can be
used and extended in support of Automatically Optical Switched used and extended in support of Automatically Optical Switched
Networks (ASON) as specified in the ITU-T G.8080 recommendation Networks (ASON) as specified in the ITU-T G.8080 recommendation
[G.8080]. Note, however, that the mechanisms that it describes and [G.8080]. Note, however, that the mechanisms that it describes and
references have a larger scope than the one described in this references have a larger scope than the one described in this
document. document.
D.Papadimitriou et al. - Expires August 2005 3
[ASON-REQ] identifies the requirements to be covered by the [ASON-REQ] identifies the requirements to be covered by the
extensions to the GMPLS signaling protocols to support the extensions to the GMPLS signaling protocols to support the
capabilities of an ASON network. capabilities of an ASON network.
D.Papadimitriou et al. - Expires January 2006 3
The following are expected from the GMPLS protocol suite to realize The following are expected from the GMPLS protocol suite to realize
the needed ASON functionality: the needed ASON functionality:
a) support for soft permanent connection functionality a) support for soft permanent connection functionality
b) support for call and connection separation b) support for call and connection separation
c) support for call segments c) support for call segments
d) support for extended restart capabilities during control plane d) support for extended restart capabilities during control plane
failures failures
e) support for extended label association e) support for extended label association
f) support for crankback capability. f) support for crankback capability.
skipping to change at line 217 skipping to change at line 215
in [G.7713]. in [G.7713].
While [G.7713.2] make use of GMPLS RSVP-TE signaling, there are key While [G.7713.2] make use of GMPLS RSVP-TE signaling, there are key
differences from the problem statement in [ASON-REQ] and the solution differences from the problem statement in [ASON-REQ] and the solution
it provides. These differences result from the development of a it provides. These differences result from the development of a
fuller and clearer set of requirements in [G.8080] after the time fuller and clearer set of requirements in [G.8080] after the time
that [G.7713.2] was published and [ASON-REQ] considerations for that [G.7713.2] was published and [ASON-REQ] considerations for
compatibility aspects with GMPLS [RFC3473]. These differences are compatibility aspects with GMPLS [RFC3473]. These differences are
enumerated below and detailed in Appendix 1. enumerated below and detailed in Appendix 1.
D.Papadimitriou et al. - Expires August 2005 4
1. As described in [G.8080], there are various models and multiple 1. As described in [G.8080], there are various models and multiple
methods of achieving connections across multiple domains. methods of achieving connections across multiple domains.
D.Papadimitriou et al. - Expires January 2006 4
[G.7713.2] is similar to a cooperative connection model between [G.7713.2] is similar to a cooperative connection model between
domains, that is, there is no overall coordination, and it uses domains, that is, there is no overall coordination, and it uses
point-to-point external NNI (E-NNI) signaling between inter- point-to-point external NNI (E-NNI) signaling between inter-
domain border controllers (i.e. single-hop LSP). Additionally, it domain border controllers (i.e. single-hop LSP). Additionally, it
requires address resolution at both border controllers regardless requires address resolution at both border controllers regardless
of the address space used. Recent enhancements to [G.8080] of the address space used. Recent enhancements to [G.8080]
include end-to-end network capabilities based on flexible (end- include end-to-end network capabilities based on flexible (end-
to-end) path selection to support optimal route selection i.e. to-end) path selection to support optimal route selection i.e.
source-based re-routing and crankback. source-based re-routing and crankback.
skipping to change at line 271 skipping to change at line 270
5. [G.7713.2] does not support call segment signaling mechanisms, as 5. [G.7713.2] does not support call segment signaling mechanisms, as
required in [G.8080] and [G.7713]. required in [G.8080] and [G.7713].
6. [G.7713.2] defines control plane restart capabilities that are 6. [G.7713.2] defines control plane restart capabilities that are
incompatible with those described in [RFC3473]. incompatible with those described in [RFC3473].
7. [G.7713.2] does not support crankback signaling mechanisms 7. [G.7713.2] does not support crankback signaling mechanisms
[GMPLS-CRANK], as required in [G.8080] and [G.7713]. [GMPLS-CRANK], as required in [G.8080] and [G.7713].
D.Papadimitriou et al. - Expires August 2005 5
3.2 Applicability 3.2 Applicability
D.Papadimitriou et al. - Expires January 2006 5
The requirements placed on the signaling plane of an optical network The requirements placed on the signaling plane of an optical network
to support the capabilities of an Automatically Switched Optical to support the capabilities of an Automatically Switched Optical
Network (see [ASON-REQ]) apply at both the network-network interface Network (see [ASON-REQ]) apply at both the network-network interface
(NNI) and the user-network interface (UNI). (NNI) and the user-network interface (UNI).
Some extensions to the core signaling features (see [RFC3473]) are Some extensions to the core signaling features (see [RFC3473]) are
required in support of some of the ASON requirements. [GMPLS-OVERLAY] required in support of some of the ASON requirements. [GMPLS-OVERLAY]
defines a common set of standard procedures at the user-network defines a common set of standard procedures at the user-network
interface (UNI). Other documents referenced in specific subsections interface (UNI). Other documents referenced in specific subsections
of this document define specific protocol extensions in support of of this document define specific protocol extensions in support of
skipping to change at line 318 skipping to change at line 316
space, which is used by GMPLS E-NNI signaling. A set of egress/ space, which is used by GMPLS E-NNI signaling. A set of egress/
ingress core node tuples share the same address space if the ingress ingress core node tuples share the same address space if the ingress
or ingress core node in the set could exchange GMPLS RSVP-TE messages or ingress core node in the set could exchange GMPLS RSVP-TE messages
among themselves. Within a control domain, the address space used by among themselves. Within a control domain, the address space used by
the core nodes to communicate among themselves MAY, but need not be the core nodes to communicate among themselves MAY, but need not be
shared with the address space used by any of the egress/ingress core shared with the address space used by any of the egress/ingress core
node tuples. node tuples.
A core node is identified by either a single IP address representing A core node is identified by either a single IP address representing
its Node ID, or by one or more un/numbered TE links that interconnect its Node ID, or by one or more un/numbered TE links that interconnect
core-nodes. A core node need only to know (and track) the interface core-nodes. A core node needs only to know (and track) the interface
addresses and/or Node IDs of client nodes to which incoming messages addresses and/or Node IDs of client nodes to which incoming messages
are directed. are directed.
Links may be either numbered or unnumbered. Further, links may be Links may be either numbered or unnumbered. Further, links may be
bundled or unbundled. See [BUNDLE] and [RFC3477], respectively. bundled or unbundled. See [BUNDLE] and [RFC3477], respectively.
(IF_ID) RSVP_HOP object processing at E-NNI boundaries follows the (IF_ID) RSVP_HOP object processing at E-NNI boundaries follows the
rules defined in [RFC3473]. rules defined in [RFC3473].
D.Papadimitriou et al. - Expires August 2005 6
2. ERO Processing 2. ERO Processing
D.Papadimitriou et al. - Expires January 2006 6
An ingress core node MAY receive and potentially reject a Path An ingress core node MAY receive and potentially reject a Path
message that contains an ERO. Such behavior is controlled by message that contains an ERO. Such behavior is controlled by
(hopefully consistent) configuration. If an ingress core node rejects (hopefully consistent) configuration. If an ingress core node rejects
a Path message due to the presence of an ERO it SHOULD return a a Path message due to the presence of an ERO it SHOULD return a
PathErr message with an error code of "Unknown object class" toward PathErr message with an error code of "Unknown object class" toward
the sender. This causes the path setup to fail. the sender. This causes the path setup to fail.
Further an ingress core node MAY accept EROs which include a sequence Further an ingress core node MAY accept EROs that include a sequence
of [<egress core node, ingress core node>]. This is to support of [<egress core node, ingress core node>]. This is to support
explicit label control on the egress core node interface. Incoming explicit label control on the egress core node interface. Incoming
EROs may also include a combination of the latter with sequence of EROs may also include a combination of the latter with sequence of
loose ingress core node addresses and/or AS numbers. If an ingress loose ingress core node addresses and/or AS numbers. If an ingress
core node rejects a Path message due to the presence of an ERO not of core node rejects a Path message due to the presence of an ERO not of
the permitted format it SHOULD return a PathErr message with an error the permitted format it SHOULD return a PathErr message with an error
code of Bad Explicit Route Object as defined in [RFC3209]. code of Bad Explicit Route Object as defined in [RFC3209].
- Path Message without ERO: when an ingress core node receives a Path - Path Message without ERO: when an ingress core node receives a Path
message from an egress core node that contains no ERO, it MUST message from an egress core node that contains no ERO, it MUST
skipping to change at line 381 skipping to change at line 378
that it includes only the subobjects from the egress core node that it includes only the subobjects from the egress core node
through the ingress core node of a neighboring E-NNI. This is to through the ingress core node of a neighboring E-NNI. This is to
allow the ingress core node to be aware of the selected link and allow the ingress core node to be aware of the selected link and
labels on the far end of the connection traversing this network. labels on the far end of the connection traversing this network.
4. Notification 4. Notification
An ingress core node MAY include a NOTIFY_REQUEST object in both the An ingress core node MAY include a NOTIFY_REQUEST object in both the
Path and Resv messages it forwards. An ingress node MAY remove the Path and Resv messages it forwards. An ingress node MAY remove the
NOTIFY_REQUEST object from the Path and Resv message before NOTIFY_REQUEST object from the Path and Resv message before
D.Papadimitriou et al. - Expires August 2005 7
forwarding it. An egress node MAY remove the NOTIFY_REQUEST object forwarding it. An egress node MAY remove the NOTIFY_REQUEST object
from the Path and Resv message before forwarding it. Core nodes may from the Path and Resv message before forwarding it. Core nodes may
D.Papadimitriou et al. - Expires January 2006 7
send Notification messages to ingress/egress core nodes, which have send Notification messages to ingress/egress core nodes, which have
included the NOTIFY_REQUEST object. included the NOTIFY_REQUEST object.
Note: the use of the Notify message for independent Call setup as Note: the use of the Notify message for independent Call setup as
defined in this document extends the one specified in [RFC-3473]. defined in this document extends the one specified in [RFC-3473].
3.2.2 User-Network Interface (UNI) 3.2.2 User-Network Interface (UNI)
At the UNI, the ingress and/or the egress nodes are not full players At the UNI, the ingress and/or the egress nodes are not full players
in the GMPLS network. Signaling information may be filtered and in the GMPLS network. Signaling information may be filtered and
skipping to change at line 437 skipping to change at line 434
LSP setup) LSP setup)
- Support of virtual concatenation with diverse path component LSPs - Support of virtual concatenation with diverse path component LSPs
- Multiple LSP association with a single call (note aspects related - Multiple LSP association with a single call (note aspects related
to recovery are detailed in [GMPLS-FUNCT] and [GMPLS-E2E]) to recovery are detailed in [GMPLS-FUNCT] and [GMPLS-E2E])
- Facilitate control plane operations by allowing operational status - Facilitate control plane operations by allowing operational status
change of the associated LSP. change of the associated LSP.
D.Papadimitriou et al. - Expires August 2005 8 D.Papadimitriou et al. - Expires January 2006 8
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 sections 5 and association of Calls with Connections are described in sections 5 and
onwards of this document. onwards of this document.
4.3 Call Segments 4.3 Call Segments
Call segments capabilities MUST be supported by both independent call Call segments capabilities MUST be supported by both independent call
setup and simultaneous call/connection setup. setup and simultaneous call/connection setup.
Procedures and (GMPLS) RSVP-TE signaling protocol extensions to Procedures and (GMPLS) RSVP-TE signaling protocol extensions to
skipping to change at line 491 skipping to change at line 488
Crankback mechanisms for (GMPLS) RSVP-TE signaling are covered in a Crankback mechanisms for (GMPLS) RSVP-TE signaling are covered in a
dedicated companion document [GMPLS-CRANK]. That document is intended dedicated companion document [GMPLS-CRANK]. That document is intended
to fulfill all the corresponding ASON requirements as well as to fulfill all the corresponding ASON requirements as well as
satisfying any other crankback needs. satisfying any other crankback needs.
4.7 Additional Error Codes 4.7 Additional Error Codes
Error codes corresponding to the mechanisms defined in this document Error codes corresponding to the mechanisms defined in this document
are specified along each section and summarized in Section 11. are specified along each section and summarized in Section 11.
D.Papadimitriou et al. - Expires August 2005 9 D.Papadimitriou et al. - Expires January 2006 9
5. Concepts and Terms 5. Concepts and Terms
The concept of a Call and a Connection are discussed in the ASON The concept of a Call and a Connection are discussed in the ASON
architecture [G.8080]. This section is not intended as a substitute architecture [G.8080]. This section is not intended as a substitute
for that document, but is a brief summary of the key terms and for that document, but is a brief summary of the key terms and
concepts. concepts.
5.1 What is a Call? 5.1 What is a Call?
skipping to change at line 545 skipping to change at line 542
- 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.
D.Papadimitriou et al. - Expires August 2005 10 D.Papadimitriou et al. - Expires January 2006 10
5.3 Exchanging Access Link Capabilities 5.3 Exchanging Access Link Capabilities
It is useful for the ingress node of an LSP to know the link It is useful for the ingress node of an LSP to know the link
capabilities of the link between the network and the egress node. capabilities of the link between the network and the egress node.
This information may allow the ingress node to tailor its LSP request This information may allow the ingress node to tailor its LSP request
to fit those capabilities and to better utilize network resources to fit those capabilities and to better utilize network resources
with regard to those capabilities. with regard to those capabilities.
In particular, this may be used to achieve end-to-end spectral In particular, this may be used to achieve end-to-end spectral
skipping to change at line 601 skipping to change at line 598
5.3.3 Utilizing Call Setup 5.3.3 Utilizing Call Setup
When IGP and EGP solutions are not available at the UNI, there is When IGP and EGP solutions are not available at the UNI, there is
still a requirement to have, at the local edge nodes, the knowledge still a requirement to have, at the local edge nodes, the knowledge
of the remote edge link capabilities. of the remote edge link capabilities.
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.
D.Papadimitriou et al. - Expires August 2005 11 D.Papadimitriou et al. - Expires January 2006 11
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 similar
to that distributed by GMPLS-capable IGPs (see [GMPLS-RTG]). to that distributed by GMPLS-capable IGPs (see [GMPLS-RTG]).
6. Protocol Extensions for Calls and Connections 6. 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 7. section 7.
skipping to change at line 656 skipping to change at line 653
naming convention(s). However, [RFC3209] defines the "Session Name" naming convention(s). However, [RFC3209] defines the "Session Name"
field as a Null padded display string, and that any formatting field as a Null padded display string, and that any formatting
conventions for the Call ID must be limited to this scope. conventions for the Call ID must be limited to this scope.
6.1.2 Short Form Call Identification 6.1.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 Call ID. Each LSP MAY carry the full long reference to the call - the Call ID. Each LSP MAY carry the full long
Call ID in the "Session Name" of the SESSION ATTRIBUTE object to Call ID in the "Session Name" of the SESSION ATTRIBUTE object to
D.Papadimitriou et al. - Expires August 2005 12 D.Papadimitriou et al. - Expires January 2006 12
achieve this purpose. However, existing (and future) implementations achieve this purpose. However, existing (and future) implementations
may need to place other strings in this field (in particular, the may need to place other strings in this field (in particular, the
field is currently intended to provide the Session Name). To allow field is currently intended to provide the Session Name). To allow
for this possibility a new field is added to the signaling protocol for this possibility a new field is added to the signaling protocol
to identify an individual LSP with the Call to which it belongs. to identify an individual LSP with the Call to which it belongs.
The new field is a 16-bit identifier (unique within the context of The 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) that MUST be exchanged during Call initialization and Sender_Address) that MUST be exchanged during Call initialization and
is used on all subsequent LSP setups that are associated with the is used on all subsequent LSP setups that are associated with the
skipping to change at line 710 skipping to change at line 707
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 to zero when there is no corresponding call. set to zero when there is no corresponding call.
Tunnel ID: 16 bits (see [RFC3209]) Tunnel ID: 16 bits (see [RFC3209])
D.Papadimitriou et al. - Expires August 2005 13 D.Papadimitriou et al. - Expires January 2006 13
Extended Tunnel ID: 32 bits/128 bits (see [RFC3209]) Extended Tunnel ID: 32 bits/128 bits (see [RFC3209])
6.2 LINK_CAPABILITY object 6.2 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. This optional object includes the bundled exchange during Call setup. This optional object includes the bundled
link local capabilities of the call initiating node (or terminating link local capabilities of the call initiating node (or terminating
node) indicated by the source address of the Notify message. node) indicated by the source address of the Notify message.
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
skipping to change at line 764 skipping to change at line 761
This object MAY also be used to exchange more than one bundled link This object MAY also be used to exchange more than one bundled link
capability. In this case, the following ordering MUST be followed: capability. In this case, the following ordering MUST be followed:
one identifier subobject (Type 1, 2 or 4) MUST be inserted before any one identifier subobject (Type 1, 2 or 4) MUST be inserted before any
capability subobject (Type 64 or 65) to which it refers. capability subobject (Type 64 or 65) to which it refers.
6.3 Revised Message Formats 6.3 Revised Message Formats
The Notify message is enhanced (and referred thereby to as an The Notify message is enhanced (and referred thereby to as an
unsolicited Notify message) to support Call establishment and unsolicited Notify message) to support Call establishment and
D.Papadimitriou et al. - Expires August 2005 14 D.Papadimitriou et al. - Expires January 2006 14
teardown of Calls that operate independent of LSPs. See section 7 for teardown of Calls that operate independent of LSPs. See section 7 for
a description of the procedures. a description of the procedures.
6.3.1 Notify Message 6.3.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 CAPABILTY 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 ATTIBUTE object carry the long Call ID. The presence of the SESSION ATTIBUTE 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.
skipping to change at line 804 skipping to change at line 801
<sender descriptor> ::= see [RFC3473] <sender descriptor> ::= see [RFC3473]
<flow descriptor> ::= see [RFC3473] <flow descriptor> ::= see [RFC3473]
6.4 ADMIN_STATUS Object 6.4 ADMIN_STATUS Object
Messages (such as Notifys, Paths, etc.) exchanged for Call control Messages (such as Notifys, Paths, etc.) exchanged for Call control
and management purposes carry a specific new bit (the Call Management and management purposes carry a specific new bit (the Call Management
or C bit) in the ADMIN STATUS object. or C bit) in the ADMIN STATUS object.
The format of the contents of the ADMIN_STATUS object are both The format and the contents of the ADMIN_STATUS object are both
dictated by [RFC3473] in favor of [RFC3471]. The new "C" bit is added dictated by [RFC3473] in favor of [RFC3471]. The new "C" bit is added
as shown below. 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]
D.Papadimitriou et al. - Expires August 2005 15 D.Papadimitriou et al. - Expires January 2006 15
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 7. The procedures for the use of the C bit are described in section 7.
Note that the use of the C bit may appear as redundant since Call Note that the use of the C bit may appear as redundant since Call
setup can be distinguished by the presence of the SESSION ATTRIBUTE setup can be distinguished by the presence of the SESSION ATTRIBUTE
object in a Notify message or an non-zero short Call ID value in a object in a Notify message or an non-zero short Call ID value in a
skipping to change at line 871 skipping to change at line 868
- A Connection may be established without any reference to a Call. - A Connection may be established without any reference to a Call.
This encompasses the previous LSP setup procedure. This encompasses the previous LSP setup procedure.
Note that a Call MAY NOT be imposed upon a Connection that is already Note that a Call MAY NOT be imposed upon a Connection that is already
established. To do so would require changing the short Call Id in the established. To do so would require changing the short Call Id in the
SESSION OBJECT of the existing LSPs and this would constitute a SESSION OBJECT of the existing LSPs and this would constitute a
change in the Session Identifier. This is not allowed by existing change in the Session Identifier. This is not allowed by existing
protocol specifications. protocol specifications.
D.Papadimitriou et al. - Expires August 2005 16 D.Papadimitriou et al. - Expires January 2006 16
Call and Connection teardown procedures are described later in Call and Connection teardown procedures are described later in
Section 7.7. Section 7.7.
7.2 Independent Call Setup 7.2 Independent Call Setup
It is possible to set up a Call before, and independent of, LSP It is possible to set up a Call before, and independent of, LSP
setup. A Call setup without LSPs MUST follow the procedure described setup. A Call setup without LSPs MUST follow the procedure described
in this section. in this section.
Prior to the LSP establishment, Call setup MAY necessitate Prior to the LSP establishment, Call setup MAY necessitate
skipping to change at line 926 skipping to change at line 923
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 during LSP-independent call establishment. The Tunnel_ID of used during LSP-independent call establishment. The Tunnel_ID of
the SESSION object is not relevant for this procedure and SHOULD the SESSION object is not relevant for this procedure and SHOULD
be set to zero. The Extended_Tunnel_ID of the SESSION object is be set to zero. The Extended_Tunnel_ID of the SESSION object is
not relevant for this procedure and MAY be set to zero or to an not relevant for this procedure and MAY be set to zero or to an
address of the ingress node. address of the ingress node.
- The SESSION ATTRIBUTE object contains priority flags. Currently no - The SESSION ATTRIBUTE object contains priority flags. Currently no
use of these flags is envisioned, however, future work may use of these flags is envisioned, however, future work may
D.Papadimitriou et al. - Expires August 2005 17 D.Papadimitriou et al. - Expires January 2006 17
identify value is assigning priorities to Calls; accordingly the identify value is 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 are relevant to this process and in the SESSION ATTRIBUTE object are 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 6. to carry the long Call Id as described in Section 6.
- 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. The
LSP_ID is not relevant and SHOULD be set to zero. LSP_ID is not relevant and SHOULD be set to zero.
skipping to change at line 980 skipping to change at line 977
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 other
bits MUST be set to zero. bits MUST be set to zero.
The responder MAY use the Message ID object to ensure reliable The responder MAY 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
D.Papadimitriou et al. - Expires August 2005 18 D.Papadimitriou et al. - Expires January 2006 18
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 7.8. liveliness procedures are covered in section 7.8.
7.2.2 Rejecting Independent Call Setup 7.2.2 Rejecting Independent Call Setup
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 the
sender has retransmitted the Notify message a configurable number of sender has retransmitted the Notify message a configurable number of
skipping to change at line 1034 skipping to change at line 1031
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 SENDER
TEMPLATE object) and the destination address (in the SESSION object). TEMPLATE object) and the destination address (in the SESSION object).
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.
D.Papadimitriou et al. - Expires August 2005 19 D.Papadimitriou et al. - Expires January 2006 19
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 and the "Session Name" match the long Call ID of the associated Call and the "Session Name"
MAY still be used to distinguish between virtually concatenated LSPs MAY still be used to distinguish between virtually concatenated LSPs
belonging to the same Call. Thus, there is not necessarily a one-to- belonging to the same Call. Thus, there is not necessarily a one-to-
one mapping between the "Session Name" of an LSP and the short one mapping between the "Session Name" of an LSP and the short
Call_ID. Call_ID.
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.
7.3.1 Adding a Reverse Direction LSP to a Call 7.3.1 Adding a Reverse Direction LSP to a Call
skipping to change at line 1088 skipping to change at line 1085
the SESSION object as described above. The reserved value of zero is the SESSION object as described above. The reserved value of zero is
used when the LSP is being set up with no association to a Call. used when the LSP is being set up with no association to a Call.
7.4.1 Accepting Simultaneous Call/Connection Setup 7.4.1 Accepting Simultaneous Call/Connection Setup
A Path message that requests simultaneous Call and Connection setup A Path message that requests simultaneous Call and Connection setup
is subject to local authorization and policy procedures applicable to is subject to local authorization and policy procedures applicable to
Call establishment in addition to the standard procedures associated Call establishment in addition to the standard procedures associated
with LSP setup described in [RFC3473]. with LSP setup described in [RFC3473].
D.Papadimitriou et al. - Expires August 2005 20 D.Papadimitriou et al. - Expires January 2006 20
If the Call and LSP setup is to be accepted, a Resv message is If the Call and LSP setup is to be accepted, a Resv message is
returned. The Resv message MUST carry the ADMIN STATUS object with returned. The Resv message MUST carry the ADMIN STATUS object with
the R bit clear and the C bit set. Other bits may be set or cleared the R bit clear and the C bit set. Other bits may be set or cleared
according to the requirements of LSP setup. The D bit MUST NOT be according to the requirements of LSP setup. The D bit MUST NOT be
set. set.
The Call ID MUST be reflected in the SESSION object. The Call ID MUST be reflected in the SESSION object.
7.4.2 Rejecting Simultaneous Call/Connection Setup 7.4.2 Rejecting Simultaneous Call/Connection Setup
skipping to change at line 1143 skipping to change at line 1140
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
D.Papadimitriou et al. - Expires August 2005 21 D.Papadimitriou et al. - Expires January 2006 21
setup that it initiated, and MUST respond to the received Call setup that it initiated, and MUST respond to the received Call
setup. setup.
In the second case, special processing is necessary if simultaneous In the second case, special processing is necessary if simultaneous
Call and Connection establishment was being used. Firstly, the node Call and Connection establishment was being used. Firstly, the node
that is discarding the Call that it initiated MUST send a PathTear that is discarding the Call that it initiated MUST send a PathTear
message to remove state from transit nodes. Secondly, this node may message to remove state from transit nodes. Secondly, this node may
want to hold onto the Connection request and establish an LSP once want to hold onto the Connection request and establish an LSP once
the Call is in place since only the Call that it was trying to the Call is in place since only the Call that it was trying to
establish has been set up by the destination - the Connection may establish has been set up by the destination - the Connection may
still be required. still be required.
A further possibility for contention arises when Call IDs are A further possibility for contention arises when 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. In this event a node receives a Call setup request simultaneously. In this event a node receives a Call setup request
carrying a short Call ID that matches one that it previously sent for carrying a short Call ID that matches one that it previously sent for
the same address pair. The following processing MUST be followed. the same address pair. The following 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 or PathErr as appropriate) with the new Error Code "Call message or PathErr message as appropriate) with the new Error Code
Management" (TBD) and the new Error Value "Call ID Contention" "Call Management" (TBD) and the new Error Value "Call ID
(TBD). Contention" (TBD).
- 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 above,
and at that point it selects a new short Call ID and re-sends the and at that point it selects a new short Call ID and re-sends the
Call setup request. Call setup request.
Note: these procedures apply for any combination of independent and Note: these procedures apply for any combination of independent and
simultaneous call establishment. simultaneous call establishment.
skipping to change at line 1198 skipping to change at line 1195
7.7.1 Removal of a Connection from a Call 7.7.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 [RFC3743]. No special procedures are standard procedures described in [RFC3743]. No special procedures are
required. 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
D.Papadimitriou et al. - Expires August 2005 22 D.Papadimitriou et al. - Expires January 2006 22
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.
7.7.2 Removal of the Last Connection from a Call 7.7.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.
skipping to change at line 1253 skipping to change at line 1250
"Connection Still Exists" (TBD). "Connection Still Exists" (TBD).
7.7.5 Teardown of a Call from the Egress 7.7.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.
If the Call was established using simultaneous Call/Connection setup If the Call was established using simultaneous Call/Connection setup
the removal of the last LSP deletes the Call. This, regardless of the removal of the last LSP deletes the Call. This, regardless of
D.Papadimitriou et al. - Expires August 2005 23 D.Papadimitriou et al. - Expires January 2006 23
whether the LSP is torn down by using a PathTear message (for an whether the LSP is torn down by using a PathTear message (for an
egress-initiated LSP) or by using a PathErr message with the egress-initiated LSP) or by using a PathErr message with the
Path_State_Removed flag set (for an ingress-initiated LSP). Path_State_Removed flag set (for an ingress-initiated LSP).
If the Call was established using independent Call/Connection setup If the Call was established using independent Call/Connection setup
and the Call is "empty" it may be deleted by the egress sending a and the Call is "empty" it may be deleted by the egress sending a
Notify message just as described above. Notify message just as described above.
Note that there is still a possibility that both ends of a Call Note that there is still a possibility that both ends of a Call
initiate a simultaneous Call deletion. In this case, the Notify initiate a simultaneous Call deletion. In this case, the Notify
skipping to change at line 1308 skipping to change at line 1305
A node that is unsure of the status of a Call MAY immediately send a A node that is unsure of the status of a Call MAY immediately send a
Notify message as if establishing the Call for the first time. Notify message as if establishing the Call for 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.
If it receives no response to a refresh Notify request (including no If it 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 is
unreachable or unavailable. It is a local policy matter whether this unreachable or unavailable. It is a local policy matter whether this
causes the local node to teardown associated LSPs and delete the causes the local node to teardown associated LSPs and delete the
Call. Call.
D.Papadimitriou et al. - Expires August 2005 24 D.Papadimitriou et al. - Expires January 2006 24
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 Call
setup never materializes the failure by the restarting node to 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) with the error code "Call Management" error (PathErr or ResvErr) with the error code "Call Management"
skipping to change at line 1362 skipping to change at line 1359
Further, the first node in the network may be responsible for Further, the first node in 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 to the first node of the core network. set up the Call is addressed to the first node of the core network.
Moreover, neither the long Call ID nor the short Call ID is supplied Moreover, neither the long Call ID nor the short Call ID is supplied
(the Session Name Length is set to zero and the Call ID value is set (the Session Name Length is set to zero and the Call ID value is set
to zero). The Notify message is passed to the first network node to zero). The Notify message is passed to the first network node
which is responsible for generating the long and short Call IDs which is responsible for generating the long and short Call IDs
before dispatching the message to the remote Call end point (which is before dispatching the message to the remote Call end point (which is
D.Papadimitriou et al. - Expires August 2005 25 D.Papadimitriou et al. - Expires January 2006 25
known from the SESSION object). Similarly, the first network node may known from the SESSION object). Similarly, the first network node may
be responsible for generating the long and short Call IDs for be responsible for generating the long and short Call IDs for
inclusion in Path messages that have the C bit set in the ADMIN inclusion in Path messages that have the C bit set in the ADMIN
STATUS object. STATUS 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 [GMPLS-OVERLAY]) to replace the Session Name assigned by allowed (see [GMPLS-OVERLAY]) to replace the Session Name assigned by
the ingress node and passed in the Path message. In the case of Call the ingress node and passed in the Path message. In the case of Call
management, the first network node MUST in addition 1) be aware that management, the first network node MUST in addition 1) be aware that
the name it inserts MUST be a long Call ID and 2) replace the long the name it inserts MUST be a long Call ID and 2) replace the long
skipping to change at line 1416 skipping to change at line 1413
9.1 Non-Support by External Call Managers 9.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 network 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.
D.Papadimitriou et al. - Expires August 2005 26 D.Papadimitriou et al. - Expires January 2006 26
- 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. 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 ID
Acknowledgement will be sent. The initiator will retry and then Acknowledgement will be sent. The initiator will retry and then
give up. give up.
- Node supports GMPLS but not Call management. The message will be - Node supports GMPLS but not Call management. The message will be
skipping to change at line 1470 skipping to change at line 1467
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
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 9.1) in the Notify message it will react (as described in Section 9.1) in the
same way as an external Call manager. same way as an external Call manager.
If the egress node does not support the use of the C bit in the ADMIN If the egress node does not support the use of the C bit in the ADMIN
STATUS object or the Call ID in the SESSION object, it MAY respond STATUS object or the Call ID in the SESSION object, it MAY respond
D.Papadimitriou et al. - Expires August 2005 27 D.Papadimitriou et al. - Expires January 2006 27
with the fields zeroed in which case the initiator will know that the with the fields zeroed in which case the initiator will know that the
Call setup has failed. Call setup has failed.
On the other hand, it is possible that the egress will respond On the other hand, it is possible that the egress will respond
copying the fields from the Path message without understanding or copying the fields from the Path message without understanding or
acting on the fields. In this case the initiator will believe that acting on the fields. In this case the initiator will believe that
the Call has been set up when it has not. This occurrence can be the Call has been set up when it has not. This occurrence can be
prevented using the independent Call setup procedures, but is, in any prevented using the independent Call setup procedures, but is, in any
case, detected when a Notify message is sent to keep the Call alive. case, detected when a Notify message is sent to keep the Call alive.
skipping to change at line 1524 skipping to change at line 1521
C-Type = 1 (TE Link Capabilities) C-Type = 1 (TE Link Capabilities)
New RSVP Error Codes and Error Values are introduced New RSVP Error Codes and Error Values are introduced
o Error Codes: o Error Codes:
- Call Management (value TBA) - Call Management (value TBA)
o Error Values: o Error Values:
D.Papadimitriou et al. - Expires August 2005 28 D.Papadimitriou et al. - Expires January 2006 28
- Call Management/Call ID Contention (value TBA) - Call Management/Call ID Contention (value TBA)
- Call Management/Connections still Exist (value TBA) - Call Management/Connections still Exist (value TBA)
- Call Management/Unknown Call ID (value TBA) - Call Management/Unknown Call ID (value TBA)
12. Acknowledgements 12. Acknowledgements
The authors would like to thank George Swallow, Yakov Rekhter, Lou The authors would like to thank George Swallow, Yakov Rekhter, Lou
Berger, Jerry Ash and Kireeti Kompella for their very useful input Berger, Jerry Ash and Kireeti Kompella for their very useful input
and comments to this document. and comments to this document.
13. References 13. References
13.1 Normative References 13.1 Normative References
[ASON-REQ] D.Papadimitriou, et al., "Requirements for [ASON-REQ] D.Papadimitriou, et al., "Requirements for
Generalized MPLS (GMPLS) Usage and Extensions for Generalized MPLS (GMPLS) Usage and Extensions for
Automatically Switched Optical Network (ASON)," Work Automatically Switched Optical Network (ASON)," Work
in progress, Oct'03. in progress, Oct'04.
[BUNDLE] K.Kompella, Y.Rekhter and L.Berger, "Link Bundling [BUNDLE] K.Kompella, Y.Rekhter and L.Berger, "Link Bundling
in MPLS Traffic Engineering," Work in Progress. in MPLS Traffic Engineering," Work in Progress.
[GMPLS-CRANK] A.Farrel (Editor) et al., "Crankback Routing [GMPLS-CRANK] A.Farrel (Editor) et al., "Crankback Routing
Extensions for MPLS Signaling," Work in progress, Extensions for MPLS Signaling," Work in progress,
Oct'04. Oct'04.
[GMPLS-FUNCT] J.P.Lang and B.Rajagopalan (Editors) et al., [GMPLS-FUNCT] J.P.Lang and B.Rajagopalan (Editors) et al.,
"Generalized MPLS Recovery Functional "Generalized MPLS Recovery Functional
skipping to change at line 1578 skipping to change at line 1575
[RFC2119] S.Bradner, "Key words for use in RFCs to Indicate [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, Mar'97. Requirement Levels," BCP 14, RFC 2119, Mar'97.
[RFC2205] R.Braden et al., "Resource ReSerVation Protocol [RFC2205] R.Braden et al., "Resource ReSerVation Protocol
(RSVP)- Version 1 Functional Specification," (RSVP)- Version 1 Functional Specification,"
RFC 2205, Sep'97 RFC 2205, Sep'97
[RFC2402] S.Kent and R.Atkinson, "IP Authentication Header," [RFC2402] S.Kent and R.Atkinson, "IP Authentication Header,"
RFC 2402, Nov'98. RFC 2402, Nov'98.
D.Papadimitriou et al. - Expires August 2005 29 D.Papadimitriou et al. - Expires January 2006 29
[RFC2406] S.Kent and R.Atkinson, "IP Encapsulating Payload [RFC2406] S.Kent and R.Atkinson, "IP Encapsulating Payload
(ESP)," RFC 2406, Nov'98. (ESP)," RFC 2406, Nov'98.
[RFC3209] D.Awduche et al., "RSVP-TE: Extensions to RSVP for [RFC3209] D.Awduche et al., "RSVP-TE: Extensions to RSVP for
LSP Tunnels," RFC 3209, Dec'01. LSP Tunnels," RFC 3209, Dec'01.
[RFC3471] L.Berger (Editor) et al., "Generalized MPLS - [RFC3471] L.Berger (Editor) et al., "Generalized MPLS -
Signaling Functional Description," RFC 3471, Jan'03. Signaling Functional Description," RFC 3471, Jan'03.
[RFC3473] L.Berger (Editor) et al., "Generalized MPLS [RFC3473] L.Berger (Editor) et al., "Generalized MPLS
skipping to change at line 1625 skipping to change at line 1622
Automatically Switched Optical Network (ASON)," RFC Automatically Switched Optical Network (ASON)," RFC
3474, Mar'03. 3474, Mar'03.
[RFC3476] B.Rajagopalan (Editor), "Documentation of IANA [RFC3476] B.Rajagopalan (Editor), "Documentation of IANA
Assignments for Label Distribution Protocol Assignments for Label Distribution Protocol
(LDP), Resource ReSerVation Protocol (RSVP), and (LDP), Resource ReSerVation Protocol (RSVP), and
Resource ReSerVation Protocol-Traffic Engineering Resource ReSerVation Protocol-Traffic Engineering
(RSVP-TE) Extensions for Optical UNI Signaling," RFC (RSVP-TE) Extensions for Optical UNI Signaling," RFC
3476, Mar'03. 3476, Mar'03.
For information on the availability of the following documents,
please see http://www.itu.int.
[G.7713] ITU-T, "Distributed Call and Connection Management," [G.7713] ITU-T, "Distributed Call and Connection Management,"
Recommendation G.7713/Y.1304, Nov'01. Recommendation G.7713/Y.1304, Nov'01.
D.Papadimitriou et al. - Expires January 2006 30
[G.7713.2] ITU-T, "DCM Signalling Mechanisms Using GMPLS RSVP- [G.7713.2] ITU-T, "DCM Signalling Mechanisms Using GMPLS RSVP-
TE," Recommendation G.7713.2, Jan'03. TE," Recommendation G.7713.2, Jan'03.
D.Papadimitriou et al. - Expires August 2005 30
[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, Nov'01 (and Revision, Jan'03). Y.1304, Nov'01 (and Revision, Jan'03).
14. Author's Addresses 14. Author's Addresses
Dimitri Papadimitriou (Alcatel) Dimitri Papadimitriou (Alcatel)
Fr. Wellesplein 1, Fr. Wellesplein 1,
B-2018 Antwerpen, Belgium B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491 Phone: +32 3 240-8491
skipping to change at line 1673 skipping to change at line 1673
EMail: zali@cisco.com EMail: zali@cisco.com
Arthi Ayyangar (Juniper) Arthi Ayyangar (Juniper)
1194 N.Mathilda Ave 1194 N.Mathilda Ave
Sunnyvale, CA 94089, USA Sunnyvale, CA 94089, USA
EMail: arthi@juniper.net EMail: arthi@juniper.net
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@nortelnetworks.com
D.Papadimitriou et al. - Expires August 2005 31 D.Papadimitriou et al. - Expires January 2006 31
Appendix 1: Analysis of G.7713.2 against GMPLS RSVP-TE Signaling Appendix 1: Analysis of G.7713.2 against GMPLS RSVP-TE Signaling
Requirements in support of ASON Requirements in support of ASON
Informational RFC [RFC3474] (and [RFC3476]) documents the code points Informational RFC [RFC3474] (and [RFC3476]) documents the code points
for the signaling extensions defined in [G.7713.2] to meet the for the signaling extensions defined in [G.7713.2] to meet the
requirements of ASON Distributed Call and Connection Management (DCM) requirements of ASON Distributed Call and Connection Management (DCM)
as specified in [G.7713]. as specified in [G.7713].
While [G.7713.2] make use of GMPLS RSVP-TE signaling, there are key While [G.7713.2] make use of GMPLS RSVP-TE signaling, there are key
skipping to change at line 1728 skipping to change at line 1728
IPv4 (or IPv6) address of the egress node for the tunnel. IPv4 (or IPv6) address of the egress node for the tunnel.
Tunnel ID Tunnel ID
A 16-bit identifier used in the SESSION that remains constant A 16-bit identifier used in the SESSION that remains constant
over the life of the tunnel. over the life of the tunnel.
Extended Tunnel ID Extended Tunnel ID
D.Papadimitriou et al. - Expires January 2006 32
A 32-bit (IPv4) or 128-bit (IPv6) identifier used in the SESSION A 32-bit (IPv4) or 128-bit (IPv6) identifier used in the SESSION
that remains constant over the life of the tunnel. Normally set that remains constant over the life of the tunnel. Normally set
D.Papadimitriou et al. - Expires August 2005 32
to all zeros. Ingress nodes that wish to narrow the scope of a to all zeros. Ingress nodes that wish to narrow the scope of a
SESSION to the ingress-egress pair may place their IP address SESSION to the ingress-egress pair may place their IP address
here as a globally unique identifier. here as a globally unique identifier.
IPv4 (or IPv6) tunnel sender address IPv4 (or IPv6) tunnel sender address
IPv4 (or IPv6) address for a sender node IPv4 (or IPv6) address for a sender node
LSP ID LSP ID
skipping to change at line 1782 skipping to change at line 1781
The situation is summarized in the following table, using the The situation is summarized in the following table, using the
following example and a connection set from node A to Z: following example and a connection set from node A to Z:
UNI E-NNI E-NNI UNI UNI E-NNI E-NNI UNI
A ----- B -- ... -- I ----- J -- .. -- M ----- N -- ... -- Y ----- Z A ----- B -- ... -- I ----- J -- .. -- M ----- N -- ... -- Y ----- Z
At node I, the GMPLS compliant [RFC3473] Path message would include At node I, the GMPLS compliant [RFC3473] Path message would include
the following information in the IP header, the SESSION and the following information in the IP header, the SESSION and
SENDER_TEMPLATE objects: SENDER_TEMPLATE objects:
D.Papadimitriou et al. - Expires January 2006 33
Source IP address (Header): Node I IP Controller Address Source IP address (Header): Node I IP Controller Address
Dest. IP address (Header): Node J IP Controller Address Dest. IP address (Header): Node J IP Controller Address
Tunnel End-point Address: Routable Node Z IP Address Tunnel End-point Address: Routable Node Z IP Address
D.Papadimitriou et al. - Expires August 2005 33
Tunnel ID: 16 bit (selected by the sender) Tunnel ID: 16 bit (selected by the sender)
Extended Tunnel ID: optionally set to Node A IP Address Extended Tunnel ID: optionally set to Node A IP Address
Tunnel Sender Address: Routable Node A IP Address Tunnel Sender Address: Routable Node A IP Address
LSP ID: 16 bit (selected by the sender) LSP ID: 16 bit (selected by the sender)
At node I, the [G.7713.2] Path message would include the following: At node I, the [G.7713.2] Path message would include the following:
Source IP address (Header): Node I IP Controller Address Source IP address (Header): Node I IP Controller Address
Dest. IP address (Header): Node J IP Controller Address Dest. IP address (Header): Node J IP Controller Address
Tunnel End-point Address: Node J IP Controller Address Tunnel End-point Address: Node J IP Controller Address
skipping to change at line 1837 skipping to change at line 1835
reference points, for the connection end-point addresses (A and reference points, for the connection end-point addresses (A and
Z, in the above example). Z, in the above example).
5. Connection end-point addresses A and Z are allowed by [G.7713.2] 5. Connection end-point addresses A and Z are allowed by [G.7713.2]
to be from different address spaces (for instance, IPv4 source to be from different address spaces (for instance, IPv4 source
and IPv6 destination or an IPv4 source and NSAP destination). and IPv6 destination or an IPv4 source and NSAP destination).
Address resolution, management of addresses, e.g., for Address resolution, management of addresses, e.g., for
uniqueness, and impact evaluation on processing performance, are uniqueness, and impact evaluation on processing performance, are
not provided in these RFCs (considered out of scope). not provided in these RFCs (considered out of scope).
D.Papadimitriou et al. - Expires January 2006 34
Note: the [ASON-REQ] addressing model of supporting only IP Note: the [ASON-REQ] addressing model of supporting only IP
addressing is aligned with ITU-T G.7713.1 (PNNI) which only uses addressing is aligned with ITU-T G.7713.1 (PNNI) which only uses
NSAP addresses, multiple address families are not supported. NSAP addresses, multiple address families are not supported.
D.Papadimitriou et al. - Expires August 2005 34
6. [G.7713.2] defines an incompatible and redundant addressing 6. [G.7713.2] defines an incompatible and redundant addressing
mechanism with [RFC3473] to support IPv4, IPv6, and NSAP mechanism with [RFC3473] to support IPv4, IPv6, and NSAP
addresses. [RFC3473] is part of a GMPLS protocol suite based on addresses. [RFC3473] is part of a GMPLS protocol suite based on
use of IPv4 and IPv6 addresses. The use of NSAP addresses with use of IPv4 and IPv6 addresses. The use of NSAP addresses with
[RFC3473] is supported by established procedures defined in [RFC3473] is supported by established procedures defined in
[RFC1884] "IPv6 Addressing Architecture", and only requiring [RFC1884] "IPv6 Addressing Architecture", and only requiring
support by border entities, e.g., DNS. Any other support for support by border entities, e.g., DNS. Any other support for
NSAP addressing is redundant with IETF supported procedures. NSAP addressing is redundant with IETF supported procedures.
[G.7713.2] provides no guidance on the operational aspects [G.7713.2] provides no guidance on the operational aspects
resulting from this modified procedure which uses a non-standard resulting from this modified procedure which uses a non-standard
skipping to change at line 1891 skipping to change at line 1889
2. Support for Soft Permanent Connections (SPC) 2. Support for Soft Permanent Connections (SPC)
A Soft Permanent Connection (SPC) is defined as a permanent A Soft Permanent Connection (SPC) is defined as a permanent
connection at the network edges and as a switched connection within connection at the network edges and as a switched connection within
the network. the network.
[G.7713.2] mandates the use of the GENERALIZED_UNI subobjects (End- [G.7713.2] mandates the use of the GENERALIZED_UNI subobjects (End-
point Connection Address and SPC_LABEL) to support SPC capability. point Connection Address and SPC_LABEL) to support SPC capability.
Thus, in addition to suffering from the problem described in Section Thus, in addition to suffering from the problem described in Section
4, it mandates the processing of an object where it should never 4, it mandates the processing of an object where it should never
D.Papadimitriou et al. - Expires January 2006 35
occur. This is because SPCs do not assume the existence of a UNI occur. This is because SPCs do not assume the existence of a UNI
signaling interface between the source and the destination user-to- signaling interface between the source and the destination user-to-
network interface. Note also that the SPC_LABEL as defined in network interface. Note also that the SPC_LABEL as defined in
D.Papadimitriou et al. - Expires August 2005 35
[G.7713.2] does not comply with the generalized label C-Type [G.7713.2] does not comply with the generalized label C-Type
definition of [RFC3473] meaning that an implementation adhering to definition of [RFC3473] meaning that an implementation adhering to
[RFC3473] cannot be the "soft" side of the connection. [RFC3473] cannot be the "soft" side of the connection.
This requires the mandatory usage of dedicated connection end-point This requires the mandatory usage of dedicated connection end-point
addresses by the ingress and egress nodes for SPC capability support. addresses by the ingress and egress nodes for SPC capability support.
The existing RECORD_ROUTE object and its capabilities get corrupted The existing RECORD_ROUTE object and its capabilities get corrupted
by the use of the dedicated end-point address subobjects falling by the use of the dedicated end-point address subobjects falling
outside of the corresponding EXPLICIT ROUTE object. outside of the corresponding EXPLICIT ROUTE object.
skipping to change at line 1946 skipping to change at line 1944
separation") or simultaneous ("logical call/connection separation") separation") or simultaneous ("logical call/connection separation")
from the connection setup (i.e. establishing a call before adding from the connection setup (i.e. establishing a call before adding
connections to the call or perform these operations simultaneously). connections to the call or perform these operations simultaneously).
Thus, with the introduction of the call concept, it is necessary to Thus, with the introduction of the call concept, it is necessary to
support a means of identifying the call. This becomes important when support a means of identifying the call. This becomes important when
calls and connections are separated and a connection must contain a calls and connections are separated and a connection must contain a
reference to its associated call. The following identification reference to its associated call. The following identification
enables this hierarchy: enables 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
D.Papadimitriou et al. - Expires January 2006 36
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) and Tunnel IDs may be unique within the destination of the Tunnel) and Tunnel IDs may be unique within
D.Papadimitriou et al. - Expires August 2005 36
the context of a Call. the context of a Call.
- LSP IDs are unique within the context of a Tunnel. - LSP IDs are unique within the context of a Tunnel.
For this purpose, [G.7713.2] introduces two new objects: a CALL_ID For this purpose, [G.7713.2] introduces two new objects: a CALL_ID
and a CALL_OPS object to be used in the Path, Resv, PathTear, and a CALL_OPS object to be used in the Path, Resv, PathTear,
PathErr, and Notify messages (note: additional requirements for PathErr, and Notify messages (note: additional requirements for
ResvErr and ResvTear messages' support are not addressed). The ResvErr and ResvTear messages' support are not addressed). The
CALL_OPS object is also referred to as a "call capability" object, CALL_OPS object is also referred to as a "call capability" object,
since it specifies the capability of the call. These objects belongs since it specifies the capability of the call. These objects belongs
to the range 224-255 defined as "RSVP will silently ignore, but to the range 224-255 defined as "RSVP will silently ignore, but
skipping to change at line 2001 skipping to change at line 1999
- Does not specify any procedure for negotiating call ingress/egress - Does not specify any procedure for negotiating call ingress/egress
node capabilities during call setup. node capabilities during call setup.
- Does not allow for call support *independently* of the initiating/ - Does not allow for call support *independently* of the initiating/
terminating nodes (the CALL_ID is attached to the ingress node) terminating nodes (the CALL_ID is attached to the ingress node)
thus restricting the flexibility in terms of call identifiers. thus restricting the flexibility in terms of call identifiers.
- Requires the inclusion of the CALL ID and CALL OPS objects in - Requires the inclusion of the CALL ID and CALL OPS objects in
PathErr messages that may be generated at transit nodes, which do PathErr messages that may be generated at transit nodes, which do
D.Papadimitriou et al. - Expires January 2006 37
not implement [G.7713.2] and so do not support these objects. not implement [G.7713.2] and so do not support these objects.
4. Call Segments 4. Call Segments
D.Papadimitriou et al. - Expires August 2005 37
[G.7713.2] cannot, by definition, support call segments signaling [G.7713.2] cannot, by definition, support call segments signaling
mechanisms, as required in [G.8080] and [G.7713], since [G.7713.2] mechanisms, as required in [G.8080] and [G.7713], since [G.7713.2]
does not support full call/connection separation. does not support full call/connection separation.
5. Control Plane Restart Capabilities 5. Control Plane Restart Capabilities
Restart capabilities are provided by GMPLS RSVP-TE signaling in case Restart capabilities are provided by GMPLS RSVP-TE signaling in case
of control plane failure including nodal and control channel faults. of control plane failure including nodal and control channel faults.
The handling of node and control channels faults is described in The handling of node and control channels faults is described in
[RFC3473] Section 9. No additional RSVP mechanisms or objects are [RFC3473] Section 9. No additional RSVP mechanisms or objects are
skipping to change at line 2055 skipping to change at line 2054
This is an informational draft and does not introduce any new This is an informational draft and does not introduce any new
security considerations. security considerations.
Please refer to each of the referenced documents for a description of Please refer to each of the referenced documents for a description of
the security considerations applicable to the features that they the security considerations applicable to the features that they
provide. provide.
Note that although [RFC3474] is an informational RFC it does document Note that although [RFC3474] is an informational RFC it does document
new protocol elements and functional behavior and as such introduces new protocol elements and functional behavior and as such introduces
new security considerations. In particular, the ability to place new security considerations. In particular, the ability to place
D.Papadimitriou et al. - Expires January 2006 38
authentication and policy details within the context of Call authentication and policy details within the context of Call
establishment may strengthen the options for security and may weaken establishment may strengthen the options for security and may weaken
the security of subsequent Connection establishment. Also the the security of subsequent Connection establishment. Also the
D.Papadimitriou et al. - Expires August 2005 38
potential to subvert accidentally or deliberately a soft permanent potential to subvert accidentally or deliberately a soft permanent
connection by establishing the soft part of the connection from a connection by establishing the soft part of the connection from a
false remote node needs to be examined. However, [RFC3474] has a false remote node needs to be examined. However, [RFC3474] has a
minimal security considerations section. minimal security considerations section.
D.Papadimitriou et al. - Expires August 2005 39 D.Papadimitriou et al. - Expires January 2006 39
Intellectual Property Statement Intellectual Property Statement
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
skipping to change at line 2112 skipping to change at line 2111
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
D.Papadimitriou et al. - Expires August 2005 40 D.Papadimitriou et al. - Expires January 2006 40
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/