One document matched: draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt
CCAMP Working Group J. Drake (Calient)
Internet Draft D. Papadimitriou (Alcatel)
Category: Standard Track A. Farrel (Movaz)
D. Brungard (ATT)
Expiration Date: October 2003 April 2003
Generalized MPLS (GMPLS) RSVP-TE Signalling
in support of Automatically Switched Optical Network (ASON)
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
This document specifies how Generalized MPLS (GMPLS) RSVP-TE
signaling may be used and extended to satisfy the requirements of
the Automatically Switched Optical Network (ASON) architecture
specified by the ITU-T. The requirements are in a companion document
"Requirements for Generalized MPLS (GMPLS) Usage and Extensions for
Automatically Switched Optical Network (ASON)."
In particular, this document details the mechanisms for setting up
Soft Permanent Connections (SPC), the necessary extensions in
delivering full and logical call/connection separation support, the
extended restart capabilities during control plane failures,
extended label usage and crankback signalling capability.
The mechanisms proposed in the present document are applicable to
any environment (including multi-area) and for any type of
interface: packet, layer-2, time-division multiplexed, lambda or
fiber switching.
D.Papadimitriou et al. - Expires October 2003 1
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
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 RFC-2119.
In addition, the reader is assumed to be familiar with the
terminology used in [RFC-3471] and [RFC-3473].
3. Introduction
This document describes how GMPLS RSVP-TE signaling [RFC-3473] can
be used and extended in support of Automatically Optical Switched
Networks (ASON) as specified in the ITU-T G.8080 recommendation
[ITUT-G.8080]. Note, however, that the mechanisms that it describes
and references have a larger scope than the one described in this
document.
[ASON-REQ] identifies the requirements to be covered by the
extensions to the GMPLS signaling protocols to support the
capabilities of an ASON network.
The following are expected from the GMPLS protocol suite to realize
the needed ASON functionality:
a) support for soft permanent connection functionality
b) support for call and connection separation
c) support for extended restart capabilities during control plane
failures
d) support for extended label usage
e) support for crankback capability.
This document is aligned with the [RSVP-CHANGE] process, which
requires evaluation of the existing protocol functionality for
achieving the requested functionality and justification for any
requested changes or new extensions. In this context, the following
summarizes the evaluation and assumptions made:
1. The requirements for LSP setup can be achieved using the peer
model described in [RFC-3473] or the overlay model described in
[GMPLS-OVERLAY]. Thus, the processing of standard objects and
functions (such as Explicit Route object and Record Route object)
are exactly as described in those documents.
2. The second is that any GMPLS RSVP object, message or procedure
not defined in this document or in a directly referenced document
is handled exactly as described in [RFC-3473], [RFC-3209] and
[RFC-2205]. An important consideration is that the procedures
introduced by this document do not introduce any forward or
backward compatibility issue.
3. The mechanisms proposed in this document are not restricted to
LSC or TDM capable interfaces, but are equally applicable to any
packet or layer-2 interfaces. As a consequence, the present
D.Papadimitriou et al. - Expires October 2003 2
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
document proposes ubiquitously applicable RSVP extensions.
3.1 Comparison with Previous Work
An Informational RFC [RFC-3474] has been produced to document
extensions to and uses of GMPLS signalling to meet the requirements
of ASON Distributed Call and Connection Management (DCM) as
specified in [ITU-T G.7713]. While RFC 3474 uses GMPLS signalling,
there are key differences with the problem statement addressed by
RFC 3484 compared with the present document. These differences lead
to a substantially different protocol solution as described in this
document. The following summarizes the key differences with respect
to RFC 3474:
- As already described, this document follows the process described
in [RSVP-CHANGE]. To minimize changes to the existing protocol and
provide backward compatibility, the existing protocol
functionality was evaluated and maximally used to achieve the
requested functionality.
- The solution here is backward and forward compatible with any new
and existing GMPLS features i.e. transit nodes do not need to be
updated to support the end-to-end features of ASON. The solution
proposed by RFC 3474 is not backward compatible because it
requires all nodes to support the GENERALIZED_UNI object as
defined by the [OIF-UNI] implementation agreement.
- This document addresses ASON DCM requirements contained in a
companion document [ASON-REQ]. Additional ASON functions such as
crankback are supported here.
- The solution described here additionally supports logical AND full
call/connection separation per ITU-T G.8080.
- The solution in this document additionally supports multiple
connections (e.g. multiple connections supporting virtual
concatenation) per call rather than limiting one connection to a
single call per ITU-T G.8080.
- The solution described here additionally allows for call support
*independently* of the initiating/terminating nodes (the call id
is not attached to a user node)
- The approach in this document gives more flexibility in terms of
call identifiers. In addition, any naming scheme can be used
(allowing even for translation).
4. Applicability
The requirements placed on the signaling plane of an optical network
to support the capabilities of an Automatically Switched Optical
Network (see [ASON-REQS]) can be met by both the peer model and the
overlay model as described below.
D.Papadimitriou et al. - Expires October 2003 3
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
Some extensions to the core signaling features ([RFC-3473]) are
required in support of some of the requirements. [GMPLS-OVERLAY]
defines a common set of standard procedures for the overlay model.
Other documents referenced in specific subsections of this document
define specific protocol extensions in support of specific ASON
requirements.
4.1 Peer Model
In the peer model, the ingress and egress nodes play a full part in
the GMPLS network from a signaling point of view. Routing
information may be fully or partially distributed to the ingress and
egress nodes. This behavior is described [RFC-3471] and [RFC-3473].
Note that this model supports a User to Network Interface (UNI)
separation. The ingress node may make an LSP setup request to the
network using standard GMPLS procedures.
4.2 Overlay Model
In the overlay model, the ingress and/or the egress nodes are not
full players in the GMPLS network. Routing information leaked to the
edge nodes is very limited. Signaling information may be filtered
and substituted by the network. This process is described in [GMPLS-
OVERLAY].
Note that this model supports a UNI separation. The ingress node may
initiate an LSP setup request to the network using standard GMPLS
procedures. The modifications to behavior described in [GMPLS-
OVERLAY] apply to the nodes within the network and not ingress or
egress nodes.
5. Soft Permanent Connection (SPC)
A Soft Permanent Connection (SPC) is defined as a permanent
connection at the network edges and as a switched connection within
the network.
SPC setup is provided using Explicit Label Control as specified in
[RFC-3473]. This solution is applicable in both the peer and overlay
models. For the overlay model, [GMPLS-OVERLAY] describes the
procedure for unambiguous identification of both the egress link and
label.
6. Call/Connection Separation
The call concept for optical networks is defined in [ITUT-G.8080]
where it is used to deliver the following capabilities:
- Verification and identification of the call initiator (prior to
LSP setup)
D.Papadimitriou et al. - Expires October 2003 4
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
- Support of virtual concatenation with diverse path component LSPs
- Multiple LSP association with a single call (note aspects related
to recovery are covered in [GMPLS-FUNCT] and [GMPLS-E2E])
- Facilitate control plane operations by allowing operational status
change of the associated LSP.
Procedures and protocol extensions to support Call setup, and the
association of Calls with Connections are described in sections 10
and onwards of this document.
7. Control Plane Restart Capabilities
Restart capabilities are provided by GMPLS RSVP-TE signaling in case
of control plane failure including nodal and control channel faults.
The handling of node and control channels faults is described in
[RFC-3473] Section 9. No additional RSVP mechanisms or objects are
required to fulfill the ASON control plane restart capabilities.
However, it should be noted that restart considerations must form
part of each of the procedures referenced from or described in this
document.
8. Extended Label Usage
Dynamic discovery of label associations as described in [ASON-REQ]
can be either performed through manual provisioning or using the
Link Management Protocol [LMP] capabilities.
9. Crankback Signaling
Crankback mechanisms for (GMPLS) RSVP-TE signaling are covered in a
dedicated companion document [GMPLS-CRANK]. That document is
intended to fulfill all the corresponding ASON requirements as well
as satisfying any other crankback needs.
10. Concepts and Terms
The concept of a Call and a Connection are discussed in the ASON
architecture [ITUT-G.8080]. This section is not intended as a
substitute for that document, but is a brief summary of the key
terms and concepts.
10.1 What is a Call?
A Call is an agreement between endpoints possibly in cooperation
with the nodes that provide access to the network. Call setup may
include capability exchange, policy, authorization and security.
A Call is used to facilitate and manage a set of Connections that
provide end to end data services. While Connections require state to
be maintained at nodes along the data path within the network, Calls
D.Papadimitriou et al. - Expires October 2003 5
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
do not involve the participation of transit nodes except to forward
the Call management requests as transparent messages.
A Call may be established and maintained independently of the
Connections that it supports.
10.2 A Hierarchy of Calls, Connections, Tunnels and LSPs
Clearly there is a hierarchical relationship between Calls and
Connections. One or more Connections may be associated to a Call. A
Connection may not be part of more than one call. A Connection may,
however, exist without a Call.
In GMPLS, a Connection is identified with a GMPLS TE Tunnel.
Commonly a Tunnel is identified with a single LSP, but it should be
noted that for protection, load balancing and many other functions,
a Tunnel may be supported by multiple parallel LSPs. The following
identification reproduces this hierarchy:
Call IDs are unique within the context of the pair of addresses that
are the source and destination of the Call.
Tunnel IDs are unique within the context of the Session (that is the
destination of the Tunnel). Applications may also find it convenient
to keep the Tunnel ID unique within the context of a Call.
LSP IDs are unique within the context of a Tunnel.
Note that the Call_ID value of zero is reserved and MUST NOT be used
during LSP-independent call establishment.
Throughout the remainder of this document, the terms LSP and Tunnel
are used interchangeably with the term Connection. The case of a
Tunnel that is supported by more than one LSP is covered implicitly.
10.3 Exchanging Access Link Capabilities
It is useful for the ingress node of an LSP to know the link
capabilities of the link between the network and the egress node.
This information may allow the ingress node to tailor its LSP
request to fit those capabilities and to better utilize network
resources with regard to those capabilities.
In particular, this may be used to achieve end-to-end spectral
routing attribute negotiation for signal quality negotiation (such
as BER) in photonic environments where network edges are signal
regeneration capable. Similarly, it may be used to provide end-to-
end spatial routing attribute negotiation in multi-area routing
environments, in particular, when TE links have been bundled based
on technology specific attributes
Call setup may provide a suitable mechanism to exchange information
for this purpose, although several other possibilities exist.
D.Papadimitriou et al. - Expires October 2003 6
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
10.3.1 Peer Networks
In peer networks, there may be no need to distribute additional link
capability information over and above the information distributed by
the TE and GMPLS extensions to the IGP. Further, it is possible that
future extensions to these IGPs will allow the distribution of more
detailed information including optical impairments.
10.3.2 Overlay Networks
In overlay networks, edge link information may not be visible within
the core network, nor (and specifically) at other edge nodes. This
may prevent an ingress from requesting suitable LSP characteristics
to ensure successful LSP setup.
Various solutions to this problem exist including the definition of
static TE links (that is, not advertised by a routing protocol)
between the core network and the edge nodes. Nevertheless, special
procedures may be necessary to advertise edge TE link information to
the edge nodes outside of the network without advertising the
information specific to the contents of the network.
In the future, when the requirements are understood on the
information that needs to be supported, TE extensions to EGPs may be
defined that provide this function.
10.3.3 Utilizing Call Setup
In the event that IGP and EGP solutions are not available in overlay
networks, there is still a requirement to advertise edge link
capabilities.
The Call setup procedure provides an opportunity to discover edge
link capabilities of remote edge nodes before LSP setup is
attempted. The LINK CAPABILITY object is defined to allow this
information to be exchanged. The information that is included in
this object is similar to that distributed by GMPLS-capable IGPs
[GMPLS-RTG].
11. Protocol Extensions for Calls and Connections
This section describes the protocol extensions needed in support of
Call identification and management of Calls and Connections.
Procedures for the use of these protocol extensions are described in
section 12.
11.1 Call Identification
As soon as the concept of a call is introduced, it is necessary to
support some means of identifying the call. This becomes
particularly important when calls and connections are separated and
connections must contain some reference to the call.
D.Papadimitriou et al. - Expires October 2003 7
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
According to [ASON-REQS], a call may be identified by a sequence of
bytes that may have considerable (but not arbitrary) length. A Call
ID of 40 bytes would not be unreasonable. It is not the place of
this document to supply rules for encoding or parsing Call IDs, but
it must provide a suitable means to communicate Call IDs within the
protocol. The full call identification as required by ASON is
referred to as the long Call ID.
The Call_ID is only relevant at the sender and receiver nodes.
Maintenance of this information in the signaling state is not
mandated at any intermediate node. Thus no change in [RFC 3473]
transit implementations is required and there are no backward
compatibility issues. Forward compatibility is maintained by using
the existing default values to indicate that no Call processing is
required.
11.1.1 Long Form Call Identification
The "Session Name" attribute of the SESSION_ATTRIBUTE Object is used
to carry the long form of the Call ID.
A unique value per call is inserted in the "Session Name" field by
the initiator of the call. Subsequent network nodes MAY inspect this
object and MUST forward this object transparently across network
interfaces until reaching the egress node. Note that the structure
of this field MAY be the object of further formatting depending on
the naming convention(s). However, [RFC-3209] defines the "Session
Name" field as a Null padded display string, and that any formatting
conventions for the Call ID must be limited to this scope.
11.1.2 Short Form Call Identification
The connections (LSPs) associated with a call need to carry a
reference to the call - the Call ID. Each LSP may carry the full
long Call ID in the "Session Name" of the SESSION ATTRIBUTE Object
to achieve this purpose. However, existing (and future)
implementations may need to place other strings in this field (in
particular, the field is currently intended to provide the Session
Name). To allow for this possibility a new field is added to the
signaling protocol to identify an individual LSP with the Call to
which it belongs.
The new field is a 16-bit identifier (unique within the context of
the Call Initiator) that is exchanged during Call initialization and
is used on all subsequent LSP setups that are associated with the
Call. This identifier is known as the short Call ID and is encoded
as described in the following section.
In the unlikely case of short Call_ID exhaustion, local node policy
decides upon specific actions to be taken. Local policy details are
outside of the scope of this document.
11.1.3 Short Form Call ID Encoding
D.Papadimitriou et al. - Expires October 2003 8
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
The short Call ID is carried in a 16-bit field in the SESSION Object
used during Call and LSP setup. The field used was previously
reserved (must be set to zero on transmission and ignored on
receipt). This ensures backward compatibility with nodes that do not
utilize calls.
The figure below shows the new version of the object.
Class = SESSION, Class-Num = 1, C-Type = 7(IPv4)/8(IPv6)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4/IPv6 Tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call_ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4/IPv6 Tunnel End Point Address: 32 bits/128 bits - see [RFC3209]
Call_ID: 16 bits
A 16-bit identifier used in the SESSION object that remains
constant over the life of the call. The Call_ID value MUST be
set to zero when there is no corresponding call.
Tunnel ID: 16 bits - see [RFC-3209]
Extended Tunnel ID: 32 bits/128 bits - see [RFC-3209]
11.2 LINK_CAPABILITY object
The LINK CAPABILITY object is introduced to support link capability
exchange during Call setup. The object includes the bundled link
local capabilities of the call initiating node (or terminating node)
indicated by the source address of the Notify message.
The Class Number is selected so that nodes that do not recognize
this object drop it silently. That is, the top bit is set and the
next bit is clear.
This object has the following format:
Class-Num = TBA (form 10bbbbbb), C_Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
D.Papadimitriou et al. - Expires October 2003 9
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents of the LINK_CAPABILITY object is defined as series of
variable-length data items called subobjects. The subobject format
is defined in [RFC-3209].
The following subobjects are currently defined:
- Type 1: the link local IPv4 address (numbered bundle) using the
format defined in [RFC-3209]
- Type 2: the link local IPv6 address (numbered bundle) using the
format defined in [RFC-3209]
- Type 4: the link local identifier (unnumbered links and bundles)
using the format defined in [RFC-3477]
- Type 64: the Maximum Reservable Bandwidth corresponding to this
bundle (see [BUNDLE])
- Type 65: the interface switching capability descriptor (see
[GMPLS-RTG]) corresponding to this bundle (see also [BUNDLE]).
Note: future revisions of this document may extend the above list.
This object MAY also be used to exchange more than one bundled link
capability. In this case, the following ordering MUST be followed:
one identifier subobject (Type 1, 2 or 4) MUST be inserted before
any capability subobject (Type 64 or 65) to which it refers.
11.3 Revised Message Formats
One message (the Notify message) is enhanced to support Call
establishment and teardown of Calls that operate independent of
LSPs. See section 12 for a description of the procedures.
11.3.1 Notify Message
The Notify message is modified in support of Call establishment by
the optional addition of the LINK CAPABILTY object. Further, the
SESSION ATTRIBUTE object is added to the <notify session> sequence
to carry the long Call ID. The presence of the SESSION ATTIBUTE
object may be used to distinguish a Notify message used for Call
management
The format of the Notify Message is as follows:
<Notify message> ::= <Common Header> [ <INTEGRITY> ]
[[ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]...]
[ <MESSAGE_ID> ]
<ERROR_SPEC>
<notify session list>
<notify session list> ::= [ <notify session list> ] <notify session>
<notify session> ::= <SESSION> [ <ADMIN_STATUS> ]
[ <POLICY_DATA>...]
D.Papadimitriou et al. - Expires October 2003 10
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
[ <LINK_CAPABILITY> ]
| <SESSION_ATTRIBUTE> ]
[ <sender descriptor> | <flow descriptor> ]
<sender descriptor> ::= see [RFC-3473]
<flow descriptor> ::= see [RFC-3473]
11.4 Administrative Status Object
Messages (Notifys, Paths, etc.) exchanged for Call control and
management purposes carry a specific new bit (the Call Management or
C bit) in the ADMIN STATUS object.
The format of the contents of the ADMIN_STATUS object are both
dictated by [RFC-3473] in favor of [RFC-3471]. The new 'C' bit is
added as shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |C|T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reflect (R): 1 bit - see [RFC-3471]
Testing (T): 1 bit - see [RFC-3471]
Administratively down (A): 1 bit - see [RFC-3471]
Deletion in progress (D): 1 bit - see [RFC-3471]
Call Management (C): 1 bit
This bit is set when the message is being used to control
and manage a Call.
The procedures for the use of the C bit are described in section 12.
Note that the use of the C bit may appear as redundant since Call
setup can be distinguished by the presence of the SESSION ATTRIBUTE
object in a Notify message or an non-zero short Call Id in a Path
message. However, in the case of lost messages and node restart,
this further distinction is useful to distinguish Path messages that
set up Calls from Path messages that belong to calls.
12. Procedures in Support of Calls and Connections
12.1 Call/Connection Setup Procedures
This section describes the processing steps for call and connection
setup. There are four cases considered:
- A Call and Connection may be established simultaneously. That is,
a Connection may be established and designated as belonging to a
new Call. It is an implementation decision how the work a the
ingress and egress points is split and whether the qualities of
D.Papadimitriou et al. - Expires October 2003 11
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
the Call are policed before, after or at the same time as those of
the Connection. In the event that the establishment of either the
Call or the Connection fails, an error is returned as described in
section 12.4.2 and neither is set up.
- A Call can be set up on its own. That is, without any associated
Connection. It is assumed that Connections will be added to the
Call at a later time, but this is neither a requirement nor
a constraint.
- A Connection may be added to an existing Call. This may happen if
the Call was set up without any associated Connections, or if a
further Connection is added to a Call that already has one or more
associated Connections.
- A Connection may be established without any reference to a Call.
This encompasses the previous LSP setup procedure.
Note that a Call MAY NOT be imposed upon a Connection that is
already established. To do so would require changing the short Call
Id in the Session Object of the existing LSPs and this would
constitute a change in the Session Identifier. This is not allowed
by existing protocol specifications.
Call and Connection teardown procedures are described later in
Section 12.7.
12.2 Independent Call Setup
It is possible to set up a Call before, and independent of, LSP
setup. A Call setup without LSPs MUST follow the procedure described
in this section.
Prior to the LSP establishment, Call setup MAY necessitate
verification of the link status and link capability negotiation
between the Call ingress node and the Call egress node. The
procedure described below is applied only once for a Call and hence
only once for the set of LSPs associated with a Call.
The Notify message (see [RFC 3473]) is used to signal the Call setup
request and response. The new Call Management (C) bit is used to
indicate that this Notify is managing a Call. The Notify message is
sent with source and destination IPv4/IPv6 address set to any of the
routable ingress/egress node addresses respectively.
At least one session MUST be listed in the <notify session list> of
the Notify message. In order to allow for long identification of the
Call the SESSION_ATTRIBUTE object is added as part of the <notify
session list>. Note that the ERROR SPEC object is not relevant in
Call setup and MUST carry the Error Code zero ('Confirmation') to
indicate that there is no error.
D.Papadimitriou et al. - Expires October 2003 12
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
During Call setup, the ADMIN STATUS object is sent with the
following bits set. Bits not listed MUST be set to zero.
R - to cause the egress to respond
C - to indicate that this message is managing a Call.
The SESSION, SESSION ATTRIBUTE, SENDER_TEMPLATE, SENDER_TSPEC
objects included in the <notify session> of the Notify message are
built as follows:
- The SESSION object includes as Tunnel_End_Point_Address any of the
call terminating (egress) node's IPv4/IPv6 routable addresses. The
Call_ID is set to a non-zero value unique within the context of
the address pairing provided by the Tunnel_End_Point_Address and
the Sender_Address from the SENDER TEMPLATE object (see below).
Note that the Call_ID value of zero is reserved and MUST NOT be
used during LSP-independent call establishment. The Tunnel_ID of
the SESSION object is not relevant for this procedure and SHOULD
be set to zero. The Extended_Tunnel_ID of the SESSION object is
not relevant for this procedure and MAY be set to zero or to an
address of the ingress node.
- The SESSION ATTRIBUTE object contains priority flags. Currently no
use of these flags is envisioned, however, future work may
identify value is assigning priorities to Calls; accordingly the
Priority fields MAY be set to non-zero values. None of the Flags
in the SESSION ATTRIBUTE object are relevant to this process and
this field SHOULD be set to zero. The Session Name field is used
to carry the long Call Id as described in Section 11.
- The SENDER_TEMPLATE object includes as Sender Address any of the
call initiating (ingress) node's IPv4/IPv6 routable addresses. The
LSP_ID is not relevant and SHOULD be set to zero.
- The bandwidth value inserted in the SENDER_TSPEC and FLOWSPEC
objects MUST be ignored upon receipt and SHOULD be set to zero
when sent.
Additionally, ingress/egress nodes that need to communicate their
respective link local capabilities may include a LINK_CAPABILITY
object in the Notify message.
The receiver of a Notify message may identify whether it is part of
Call management or reporting an error by the presence or absence of
the SESSION ATTRIUBTE object in the <notify session list>. Full
clarity, however, may be achieved by inspection of the new Call
Management (C) bit in the ADMIN STATUS object.
Note that the POLICY_DATA object may be included in the <notify
session list> and may be used to identify requestor credentials,
account numbers, limits, quotas, etc. This object is opaque to RSVP,
which simply passes it to policy control when required.
D.Papadimitriou et al. - Expires October 2003 13
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
Message IDs MUST be used during independent Call setup.
12.2.1 Accepting Independent Call Setup
A node that receives a Notify message carrying the ADMIN STATUS
object with the R and C bits set is being requested to set up a
Call. The receiver may perform authorization and policy according to
local requirements.
If the Call is acceptable, the receiver responds with a Notify
message reflecting the information from the Call request with two
exceptions.
- The responder removes any LINK CAPABLITY object that was received
and MAY insert a LINK CAPABILITY object that describes its own
access link.
- The ADMIN STATUS object is sent with only the C bit set. All other
bits MUST be set to zero.
The responder MAY use the Message ID object to ensure reliable
delivery of the response. If no Message ID Acknowledgement is
received after the configured number of retries, the responder
should continue to assume that the Call was successfully
established. Call liveliness procedures are covered in section 12.8.
12.2.2 Rejecting Independent Call Setup
Call setup may fail or be rejected.
If the Notify message can not be delivered, no Message ID
acknowledgement will be received by the sender. In the event that
the sender has retransmitted the Notify message a configurable
number of times without receiving a Message ID Acknowledgement (as
described in [RFC-3473]), the initiator SHOULD declare the Call
failed and SHOULD send a Call teardown request (see section 12.7).
It is also possible that a Message ID Acknowledgement is received
but no Call response Notify message is received. In this case, the
initiator MAY re-send the Call setup request a configurable number
of times (see Section 12.8) before declaring the Call has failed. At
this point the initiator MUST send a Call teardown request (see
Section 12.7).
If the Notify message cannot be parsed or is in error it MAY be
responded to with a Notify message carrying the error code 13
('Unknown object class') or 14 ('Unknown object C-Type').
The Call setup may be rejected by the receiver because of security,
authorization or policy reasons. Suitable error codes already exist
and can be used in the ERROR SPEC object included in the Notify
message sent in response.
D.Papadimitriou et al. - Expires October 2003 14
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
Error response Notify messages SHOULD also use the Message ID object
to achieve reliable delivery. No action should be taken on the
failure to receive a Message ID Acknowledgement after the configured
number of retries.
12.3 Adding a Connections to a Call
Once a Call has been established, LSPs can be added to the Call.
Since the short Call ID is part of the SESSION Object, any LSP that
has the same Call ID value in the SESSION Object belongs to the same
Call. There will be no confusion between LSPs that are associated
with a Call and those which are not since the Call ID value MUST be
equal to zero for LSPs which are not associated with a Call.
LSPs for different Calls can be distinguished because the Call ID is
unique within the context of the source address (in the SENDER
TEMPLATE) and the destination address (in the SESSION).
Ingress and egress nodes may group together LSPs associated with the
same call and process them as a group according to implementation
requirements. Transit nodes need not be aware of the association of
multiple LSPs with the same Call.
The ingress node MAY choose to set the "Session Name" of an LSP to
match the long Call ID of the associated Call and the "Session Name"
MAY still be used to distinguish between virtually concatenated LSPs
belonging to the same Call. Thus, there is not necessarily a one-to-
one mapping between the "Session Name" of an LSP and the short
Call_ID.
The C bit of the ADMIN STATUS object MUST NOT be set on LSP
messages.
12.3.1 Adding a Reverse Direction LSP to a Call
Note that once a Call has been established it is symmetric. That is,
either end of the Call may add LSPs to the Call.
Special care is needed when managing LSPs in the reverse direction
since the addresses in the SESSION and SENDER TEMPLATE are reversed.
However, since the short Call ID is unique in the context of a given
ingress-egress address pair it may safely be used to associate the
LSP with the Call.
12.4 Simultaneous Call/Connection Setup
It is not always necessary to establish a Call before adding
Connections to the Call. Where the features made available by
independent Call setup are not required, a simplification can be
made by establish a Call at the same time as the first Connection
associated to the Call.
D.Papadimitriou et al. - Expires October 2003 15
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
Simultaneous Call and LSP setup requires the usage of Call
identification and an indication that a Call is being managed. No
other protocol mechanisms beyond those described in [RFC-3473] are
needed. Normal RSVP-TE GMPLS processing takes place.
The Path message used to simultaneously set up the Call and LSP MUST
carry the ADMIN STATUS object with the R and C bits set. Other bits
may be set or cleared according to the requirements of LSP setup.
The D bit MUST NOT be set.
The Path message MUST also carry the long Call ID in the Session
Name field of the SESSION ATTRIBUTE Object as described above. This
field is not available to contain a Session Name distinct from the
Call ID.
A non-zero short Call ID MUST be placed in the new Call ID field of
the SESSION Object as described above. The reserved value of zero is
used when the LSP is being set up with no association to a Call.
12.4.1 Accepting Simultaneous Call/Connection Setup
A Path message that requests simultaneous Call and Connection setup
is subject to local authorization and policy procedures applicable
to Call establishment in addition to the standard procedures
associated with LSP setup described in [RFC-3473].
If the Call and LSP setup is to be accepted, a Resv message is
returned. The Resv message MUST carry the ADMIN STATUS object with
the R bit clear and the C bit set. Other bits may be set or cleared
according to the requirements of LSP setup. The D bit MUST NOT be
set.
The Call ID must be reflected in the SESSION object.
12.4.2 Rejecting Simultaneous Call/Connection Setup
The Path message that is sent to set up a Call and Connection
simultaneously may fail or be rejected.
Failures may include all those reasons described in [RFC-3473].
Additionally, policy and authorization reasons specifically
associated with Call setup may cause the Path message to be
rejected.
The PathErr message is issued to signal such failures and no new
error codes are required. It is RECOMMENDED that the procedures for
PathErr with state removal described in [RFC-3473] is used during
Call setup failure processing.
12.5 Call-Free Connection Setup
It continues to be possible to set up LSPs as per [RFC-3473] without
associating them with a Call. If the short Call ID in the SESSION
D.Papadimitriou et al. - Expires October 2003 16
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
Object is set to zero, there is no associated Call and the Session
Name field in the SESSION ATTRIBUTE Object SHOULD be interpreted
simply as the name of the session (see [RFC-3209]).
The new C bit in the ADMIN STATUS SHOULD be set to zero in such
messages and MUST be ignored if the Call ID is zero.
12.6 Call Collision
Since Calls are symmetrical, it is possible that both ends of a call
will attempt to establish a Call with the same long Call ID at the
same time. This is only an issue if the source and destination
address pair matches. This situation can be avoided by applying some
rules to the contents of the long Call ID, but that is outside the
scope of this document.
If a node that has sent a Call setup request and has not yet
received a response, itself receives a Call setup request with the
same long Call ID and matching source/destination addresses it
should process as follows.
- If its source address is numerically greater than the remote
source address, it MUST discard the received message and continue
to wait for a response to its setup request.
- If its source address is numerically smaller than the remote
source address, it MUST discard state associated with the Call
setup that it initiated, and MUST respond to the received Call
setup.
In the second case, special processing is necessary if simultaneous
Call and Connection establishment was being used. Firstly, the node
that is discarding the Call that it initiated MUST send a PathTear
message to remove state from transit nodes. Secondly, this node may
want to hold onto the Connection request and establish an LSP once
the Call is in place since only the Call that it was trying to
establish has been set up by the destination - the Connection may
still be required.
A further possibility for contention arises when Call IDs are
assigned by a pair of nodes for two distinct Calls that are set up
simultaneously. In this event a node receives a Call setup request
carrying a short Call ID that matches one that it previously sent
for the same address pair. The following processing MUST be
followed.
- If the receiver's source address is numerically greater than the
remote source address, the receiver returns an error (Notify
message or PathErr as appropriate) with the new Error Code 'Call
Management' (TBD) and the new Error Value 'Call ID Contention'
(TBD).
- If the receiver's source address is numerically less than the
D.Papadimitriou et al. - Expires October 2003 17
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
remote source address, the receiver accepts and processes the Call
request. It will receive an error message sent as described above,
and at that point it selects a new short Call ID and re-sends the
Call setup request.
12.7 Call/Connection Teardown
As with Call/Connection setup, there are several cases to consider.
- Removal of a Connection from a Call
- Removal of the last Connection from a Call
- Teardown of an 'empty' Call
The case of tearing down an LSP that is not associated with a Call
does not need to be examined as it follows exactly the procedures
described in [RFC-3473].
12.7.1 Removal of a Connection from a Call
An LSP that is associated with a Call may be deleted using the
standard procedures described in [RFC-3743]. No special procedures
are required.
Note that it is not possible to remove an LSP from a Call without
deleting the LSP. It is not valid to change the short Call ID from
non-zero to zero since this involves a change to the SESSION object,
which is not allowed.
12.7.2 Removal of the Last Connection from a Call
When the last LSP associated with a Call is deleted the question
arises as to what happens to the Call. Since a Call may exist
independently of Connections, it is not always acceptable to say
that the removal of the last LSP from a Call removes the Call.
If the Call was set up using independent Call setup (that is, using
a Notify message) the removal of the last LSP does not remove the
Call and the procedures described in the next section MUST be used
to delete the Call.
If the Call was set up using simultaneous Call/Connection
establishment, the removal of the last LSP does remove the Call and
the Call ID becomes invalid.
12.7.3 Teardown of an 'Empty' Call
When all LSPs have been removed from a Call that was set up
independent of Connections, the Call may be torn down or left for
use by future LSPs.
Deletion of such Calls is achieved by sending a Notify message just
as for Call setup, but the ADMIN STATUS object carries the R, D and
D.Papadimitriou et al. - Expires October 2003 18
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
C bits on the teardown request and the D and C bits on the teardown
response. Other bits MUST be set to zero.
When a Notify message is sent for deleting a call and the initiator
does not receive the corresponding reflected Notify message (or
possibly even the Message ID Ack), the initiator MAY retry the
deletion request using the same retry procedures as used during Call
establishment. If no response is received after full retry, the node
deleting the Call MAY declare the Call deleted, but under such
circumstances the node SHOULD avoid re-using the long or short Call
IDs for at least the five times the Notify refresh period.
12.7.4 Tearing a Call with Existing Connections
If a Notify request with the D bit of the ADMIN STATUS object set is
received for a Call for which LSPs still exist, the request MUST be
rejected with the Error Code 'Call Management' (TBD) and Error Value
'Connection Still Exists' (TBD).
12.7.5 Tearing a Call from the Egress
Since Calls are symmetric they may be torn down from the ingress or
egress.
If the Call was established using simultaneous Call/Connection setup
the removal of the last LSP deletes the Call. This, regardless of
whether the LSP is torn down by using a PathTear message (for an
egress-initiated LSP) or by using a PathErr message with the
Path_State_Removed flag set (for an ingress-initiated LSP).
If the Call was established using independent Call/Connection setup
and the Call is 'empty' it may be deleted by the egress sending a
Notify message just as described above.
Note that there is still a possibility that both ends of a Call
initiate a simultaneous Call deletion. In this case, the Notify
message acting as teardown request is interpreted by its recipient
as a teardown response. Since the Notify messages carry the R bit in
the ADMIN STATUS object, they are responded to anyway. If a teardown
request Notify message is received for an unknown Call ID it is,
nevertheless, responded to in the affirmative.
12.8 Control Plane Survivability
Delivery of Notify messages is secured using message ID
acknowledgements as described in previous sections.
Notify messages provide end-to-end communication that does not rely
on constant paths through the network but are routed according to
IGP routing information. No consideration is, therefore, required
for network resilience (for example, make-before-break, protection,
fast re-route), although end-to-end resilience is of interest for
node restart and completely disjoint networks.
D.Papadimitriou et al. - Expires October 2003 19
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
Periodic Notify messages SHOULD be sent by the initiator and
terminator of the Call to keep the Call alive and to handle ingress
or egress node restart. The time period for these retransmissions is
a local matter, but it is RECOMMENDED that this period should be
twice the refresh period of the LSPs associated with the Call. The
Notify messages are identical to those sent as if establishing the
Call for the first time. A node that receives a refresh Notify
message MUST respond with a Notify response. A node that receives a
refresh Notify message (response or request) MAY reset its timer -
thus, in normal processing, Notify refreshes involve a single
exchange once per time period.
A node that is unsure of the status of a Call MAY immediately send a
Notify message as if establishing the Call for the first time.
Failure to receive a refresh Notify request has no meaning. If it
receives no response to a refresh Notify request (including no
Message ID Acknowledgement) a node MAY assume that the remote node
is unreachable or unavailable. It is a local policy matter whether
this causes the local node to teardown associated LSPs and delete
the Call.
In the event that an edge node restarts without preserved state, it
MAY relearn LSP state from adjacent nodes and Call state from remote
nodes. If a Path or Resv message is received with a non-zero Call ID
but without the C bit in the ADMIN STATUS, and for a Call ID that is
not recognized, the receiver is RECOMMENDED to assume that the Call
establishment is delayed and ignore the received message. If the
Call setup never materializes the failure by the restarting node to
refresh state will cause the LSPs to be torn down. Optionally, the
receiver of such an LSP message for an unknown Call ID may return an
error (PathErr or ResvErr) with the error code 'Call Management'
(TBD) and Error Value 'Unknown Call ID' (TBD).
13. Applicability of Call and Connection Procedures
This section considers the applicability of the different Call
establishment procedures to different network models. This section
is informative and is not intended to prescribe nor prevent other
options.
13.1 Peer Model
Both independent and simultaneous Call/Connection setup are
appropriate in this model.
Since the access link properties and other traffic-engineering
attributes are likely known through the IGP, the LINK CAPABILITY
object is not usually required.
13.2 Multi-Area Networks
D.Papadimitriou et al. - Expires October 2003 20
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
Both independent and simultaneous Call/Connection setup are
appropriate in this model.
Possibly, access link properties and other traffic-engineering
attributes are not known since the areas do not leak this sort of
information. In this case, the independent Call setup mechanism may
be preferred to allow the inclusion of the LINK CAPABILITY object.
13.3 Overlay Model
Both independent and simultaneous Call/Connection setup are
appropriate in this model.
It is possible in this model that access link properties and other
traffic-engineering attributes are not shared across the core
network. In this case, the independent Call setup mechanism may be
preferred to allow the inclusion of the LINK CAPABILITY object.
Further, the first node in the network may be responsible for
managing the Call. In this case, the Notify message that is used to
set up the Call is addressed to the first node of the core network.
Moreover, neither the long Call ID nor the short Call ID is supplied
(the Session Name Length is set to zero and the Call ID value is set
to zero). The Notify message is passed to the first network node
which is responsible for generating the long and short Call IDs
before dispatching the message to the remote Call end point (which
is known from the SESSION object). Similarly, the first network node
may be responsible for generating the long and short Call IDs for
inclusion in Path messages that have the C bit set in the ADMIN
STATUS object.
Further, when used in an overlay context, the first core node is
allowed ([GMPLS-OVERLAY]) to replace the Session Name assigned by
the ingress node and passed in the Path message. In the case of Call
management, the first network node MUST in addition 1) be aware that
the name it inserts MUST be a long Call ID and 2) replace the long
Call ID when it returns the Resv message to the ingress node.
13.4 External Call Managers
Third-party Call management agents may be used to apply policy and
authorization at a point that is neither the initiator nor
terminator of the Call. The previous example in the overlay model is
a special example of this, but the process and procedures are
identical.
14. Non-support of Call ID
It is important that the procedures described above operate as
seamlessly as possible with legacy nodes that do not support the
extensions described.
D.Papadimitriou et al. - Expires October 2003 21
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
Clearly there is no need to consider the case where the Call
initiator does not support Call setup initiation.
14.1 Non-Support by External Call Managers
It is unlikely that a Call initiator will be configured to send Call
establishment Notify requests to an external Call manager including
the first network node, if that node does not support Call setup.
A node that receives an unexpected Call setup request will fall into
one of the following categories.
- Node does not support RSVP. The message will fail to be delivered
or responded. No Message ID Acknowledgement will be sent. The
initiator will retry and then give up.
- Node supports RSVP or RSVP-TE but not GMPLS. The message will be
delivered but not understood. It will be discarded. No Message ID
Acknowledgement will be sent. The initiator will retry and then
give up.
- Node supports GMPLS but not Call management. The message will be
delivered, but parsing will fail because of the presence of the
SESSION ATTRIBUTE object. A Message ID Acknowledgement may be sent
before the parse fails. When the parse fails the Notify message
may be discarded in which case the initiator will retry and then
give up, alternatively a parse error may be generated and returned
in a Notify message which will indicate to the initiator that Call
management is not set up.
14.2 Non-Support by Transit Node
Transit nodes SHOULD not examine Notify messages that are not
addressed to them. However, they will see short Call IDs in all LSPs
associated with Calls. Further, they will see the C bit in the ADMIN
STATUS object of Path and Resv messages that are used to establish
Calls.
Previous specifications state that these fields SHOULD be ignored on
receipt and MUST be transmitted as zero. This is interpreted by some
implementations as meaning that the fields should be zeroed before
the objects are forwarded. If this happens, LSP setup (and so
possibly Call setup if simultaneous establishment is used) will not
be possible. If either of the fields is zeroed either on the Path or
the Resv message, the Resv will reach the initiator with the field
set to zero - this is indication to the initiator that some node in
the network is preventing Call management. Use of Explicit Routes
may help to mitigate this issue by avoiding such nodes. The use of
independent Call setup may also help since it removes the need for
the C bit in the Path and Resv messages. Ultimately, however, it may
be necessary to upgrade the offending nodes to handle these protocol
extensions.
D.Papadimitriou et al. - Expires October 2003 22
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
14.3 Non-Support by Egress Node
It is unlikely that an attempt will be made to set up a Call to
remote node that does not support Calls.
If the egress node does not support Call management through the
Notify message it will react (as described in Section 14.1) in the
same way as an external Call manager.
If the egress node does not support the use of the C bit in the
ADMIN STATUS object or the Call ID in the SESSION object, it MAY
respond with the fields zeroed in which case the initiator will know
that the Call setup has failed.
On the other hand, it is possible that the egress will respond
copying the fields from the Path message without understanding or
acting on the fields. In this case the initiator will believe that
the Call has been set up when it has not. This occurrence can be
prevented using the independent Call setup procedures, but is, in
any case, detected when a Notify message is sent to keep the Call
alive.
15. Security Considerations
Please refer to each of the referenced documents for a description
of the security considerations applicable to the features that they
provide.
15.1 Call and Connection Security Considerations
Call setup is vulnerable to attacks both of spoofing and denial of
service. Since Call setup uses either Path messages or Notify
messages, the process can be protected by the measures applicable to
securing those messages as described in [RFC-3471], [RFC-3209] and
[RFC-2205].
Note, additionally, that the process of Call establishment
independent of LSP setup may be used to apply an extra level of
authentication and policy to hop-by-hop LSP setup. It may be
possible to protect the Call setup exchange using end-to-end
security mechanisms such as those provided by Insect ([RFC-2402] and
[RFC-2406]).
16. IANA Considerations
A new RSVP object is introduced:
o LINK CAPABILITY object
Class-Num = TBA (form 10bbbbbb)
The Class Number is selected so that nodes not recognizing
this object fail drop it silently. That is, the top bit is set
and the next bit is clear.
D.Papadimitriou et al. - Expires October 2003 23
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
C-Type = 1 (TE Link Capabilities)
New RSVP Error Codes and Error Values are introduced
o Error Codes:
- 'Call Management' (TBD)
o Error Values:
- 'Call Management/Call ID Contention' (TBD)
- 'Call Management/Connections Still Exist' (TBD)
- 'Call Management/Unknown Call ID' (TBD)
17. Acknowledgements
The authors would like to thank George Swallow, Yakov Rekhter, Lou
Berger and Jerry Ash for their very useful input and comments to
this document.
18. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
19. References
19.1 Normative References
[ASON-REQ] D.Papadimitriou, et al., " Requirements for
Generalized MPLS (GMPLS) Usage and Extensions for
Automatically Switched Optical Network (ASON)," Work
in progress, Apr'03.
[BUNDLE] K.Kompella, Y.Rekhter and L.Berger, "Link Bundling
D.Papadimitriou et al. - Expires October 2003 24
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
in MPLS Traffic Engineering," Work in Progress.
[GMPLS-CRANK] A.Farrel (Editor) et al., "Crankback Routing
Extensions for MPLS Signaling," Work in progress,
Mar'03.
[GMPLS-FUNCT] J.P.Lang and B.Rajagopalan (Editors) et al.,
"Generalized MPLS Recovery Functional
Specification," Work in Progress, Jan'03.
[GMPLS-OVERLAY] G.Swallow et al., "GMPLS RSVP Support for the
Overlay Model," Work in Progress, Feb'03.
[GMPLS-ROUTING] K.Kompella and Y.Rekhter (Editors) et al., "Routing
Extensions in Support of Generalized MPLS," Work in
Progress, Aug'02.
[LMP] J.P.Lang (Editor) et al. "Link Management Protocol
(LMP) - Version 1," Work in progress, Oct'02.
[RFC-2026] S.Bradner, "The Internet Standards Process --
Revision 3," BCP 9, RFC 2026, Oct'96.
[RFC-2119] S.Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, Mar'97.
[RFC-2205] R.Braden et al., "Resource ReSerVation Protocol
(RSVP)- Version 1 Functional Specification,"
RFC 2205, Sep'97
[RFC-3209] D.Awduche et al., "RSVP-TE: Extensions to RSVP for
LSP Tunnels," RFC 3209, Dec'01.
[RFC-3471] L.Berger (Editor) et al., "Generalized MPLS -
Signaling Functional Description," RFC 3471, Jan'03.
[RFC-3473] L.Berger (Editor) et al., "Generalized MPLS
Signaling - RSVP-TE Extensions," RFC 3473, Jan'03.
[RFC-3477] K.Kompella and Y.Rekhter, "Signalling Unnumbered
Links in Resource ReSerVation Protocol - Traffic
Engineering (RSVP-TE)," RFC 3477, Jan'03.
19.2 Informative References
[RSVP-CHANGE] K.Kompella and J.P.Lang, "Procedures for Modifying
RSVP," Work in Progress, draft-kompella-rsvp-change-
00.txt, Feb'03.
[RFC-2402] S.Kent and R.Atkinson, "IP Authentication Header,"
RFC 2402, Nov'98.
[RFC-2406] S.Kent and R.Atkinson, "IP Encapsulating Payload
D.Papadimitriou et al. - Expires October 2003 25
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
(ESP)," RFC 2406, Nov'98.
[RFC-3474] Z.Lin (Editor), " Documentation of IANA assignments
for Generalized MultiProtocol Label Switching
(GMPLS) Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) Usage and Extensions for
Automatically Switched Optical Network (ASON)," RFC
3474, Mar'03.
[ITUT-G.8080] ITU-T, "Architecture for the Automatically Switched
Optical Network (ASON)," Recommendation G.8080/
Y.1304, Nov'01 (and Revision, Jan'03).
20. Author's Addresses
Dimitri Papadimitriou (Alcatel)
Fr. Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: dimitri.papadimitriou@alcatel.be
John Drake (Calient)
5853 Rue Ferrari,
San Jose, CA 95138, USA
Phone: +1 408 972-3720
Email: jdrake@calient.net
Adrian Farrel (Movaz Networks)
7926 Jones Branch Drive,
McLean, VA 22102, USA
Phone: +1 703 847-1867
Email: afarrel@movaz.com
Deborah Brungard (AT&T)
Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ 07748, USA
Phone: +1 732 420-1573
Email: dbrungard@att.com
D.Papadimitriou et al. - Expires October 2003 26
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt April 2003
Full Copyright Statement
"Copyright (C) The Internet Society 2003. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
D.Papadimitriou et al. - Expires October 2003 27
| PAFTECH AB 2003-2026 | 2026-04-23 11:37:01 |