draft-ietf-ccamp-gmpls-rsvp-te-call-03.txt   draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt 
Network Working Group D. Papadimitriou (Alcatel) Network Working Group D. Papadimitriou (Alcatel)
Internet Draft A. Farrel (Old Dog Consulting) Internet Draft A. Farrel (Old Dog Consulting)
Updates RFC 3473 Updates RFC 3473
Proposed Category: Standard Track Proposed Category: Standard Track
Expiration Date: July 2007 January 2007 Expiration Date: July 2007 January 2007
Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions
in support of Calls in support of Calls
draft-ietf-ccamp-gmpls-rsvp-te-call-03.txt draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 2, line 5 skipping to change at page 2, line 5
This document specifies how GMPLS RSVP-TE signaling may be used and This document specifies how GMPLS RSVP-TE signaling may be used and
extended to support Calls. These mechanisms provide full and logical extended to support Calls. These mechanisms provide full and logical
Call/Connection separation. Call/Connection separation.
The mechanisms proposed in this document are applicable to any The mechanisms proposed in this document are applicable to any
environment (including multi-area), and for any type of interface: environment (including multi-area), and for any type of interface:
packet, layer-2, time-division multiplexed, lambda, or fiber packet, layer-2, time-division multiplexed, lambda, or fiber
switching. switching.
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
Table of Content Table of Content
1. Conventions used in this document ............................. 3 1. Conventions used in this document ............................. 3
2. Introduction .................................................. 3 2. Introduction .................................................. 3
2.1 Applicability to ASON ........................................ 4 2.1 Applicability to ASON ........................................ 4
3. Requirements .................................................. 4 3. Requirements .................................................. 4
3.1 Basic Call Function .......................................... 4 3.1 Basic Call Function .......................................... 4
3.2 Call/Connection Separation ................................... 4 3.2 Call/Connection Separation ................................... 4
3.3 Call Segments ................................................ 5 3.3 Call Segments ................................................ 5
skipping to change at page 3, line 5 skipping to change at page 3, line 5
6.7 Control Plane Survivability ................................. 20 6.7 Control Plane Survivability ................................. 20
7. Applicability of Call and Connection Procedures .............. 21 7. Applicability of Call and Connection Procedures .............. 21
7.1 Network-initiated Calls ..................................... 21 7.1 Network-initiated Calls ..................................... 21
7.2 User-initiated Calls ........................................ 21 7.2 User-initiated Calls ........................................ 21
7.3 External Call Managers ...................................... 22 7.3 External Call Managers ...................................... 22
7.3.1 Call Segments ............................................. 22 7.3.1 Call Segments ............................................. 22
8. Non-support of Call ID ....................................... 22 8. Non-support of Call ID ....................................... 22
8.1 Non-Support by External Call Managers ....................... 23 8.1 Non-Support by External Call Managers ....................... 23
8.2 Non-Support by Transit Node ................................. 23 8.2 Non-Support by Transit Node ................................. 23
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
8.3 Non-Support by Egress Node .................................. 24 8.3 Non-Support by Egress Node .................................. 24
9. Security Considerations ...................................... 24 9. Security Considerations ...................................... 24
9.1 Call and Connection Security Considerations ................. 24 9.1 Call and Connection Security Considerations ................. 24
10. IANA Considerations ......................................... 25 10. IANA Considerations ......................................... 25
10.1 RSVP Objects ............................................... 25 10.1 RSVP Objects ............................................... 25
10.2 RSVP Error Codes and Error Values .......................... 25 10.2 RSVP Error Codes and Error Values .......................... 25
10.3 RSVP ADMIN_STATUS object Bits .............................. 25 10.3 RSVP ADMIN_STATUS object Bits .............................. 26
11. Acknowledgements ............................................ 26 11. Acknowledgements ............................................ 26
12. References .................................................. 26 12. References .................................................. 26
12.1 Normative References ....................................... 26 12.1 Normative References ....................................... 26
12.2 Informative References ..................................... 27 12.2 Informative References ..................................... 27
13. Contact Addresses ........................................... 28 13. Contact Addresses ........................................... 28
14. Authors' Addresses .......................................... 28 14. Authors' Addresses .......................................... 28
1. Conventions used in this document 1. 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",
skipping to change at page 4, line 5 skipping to change at page 4, line 5
A Call may be associated with zero, one, or more than one Connection, A Call may be associated with zero, one, or more than one Connection,
and a Connection may be associated with zero or one Call. Thus full and a Connection may be associated with zero or one Call. Thus full
and logical Call/Connection separation is needed. and logical Call/Connection separation is needed.
An example of the requirement for Calls can be found in the ITU-T's An example of the requirement for Calls can be found in the ITU-T's
Automatically Switched Optical Network (ASON) architecture [G.8080] Automatically Switched Optical Network (ASON) architecture [G.8080]
and specific requirements for support of Calls in this context can be and specific requirements for support of Calls in this context can be
found in [RFC4139]. Note, however, that while the mechanisms found in [RFC4139]. Note, however, that while the mechanisms
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
described in this document meet the requirements stated in [RFC4139], described in this document meet the requirements stated in [RFC4139],
they have wider applicability. they have wider applicability.
The mechanisms defined in this document are equally applicable to any The mechanisms defined in this document are equally applicable to any
packet (PSC) interface, layer-2 interfaces (L2SC), TDM capable packet (PSC) interface, layer-2 interfaces (L2SC), TDM capable
interfaces, LSC interfaces, or FSC interfaces. The mechanisms and interfaces, LSC interfaces, or FSC interfaces. The mechanisms and
protocol extensions are backward compatible, and can be used for Call protocol extensions are backward compatible, and can be used for Call
management where only the Call Managers need to be aware of the management where only the Call Managers need to be aware of the
protocol extensions. protocol extensions.
skipping to change at page 5, line 5 skipping to change at page 5, line 5
association of Calls with Connections are described in Section 5 and association of Calls with Connections are described in Section 5 and
onwards of this document. onwards of this document.
3.2 Call/Connection Separation 3.2 Call/Connection Separation
Full and logical Call and Connection separation is required. That is: Full and logical Call and Connection separation is required. That is:
- It MUST be possible to establish a Connection without dependence - It MUST be possible to establish a Connection without dependence
on a Call. on a Call.
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
- It MUST be possible to establish a Call without any associated - It MUST be possible to establish a Call without any associated
Connections. Connections.
- It MUST be possible to associate more than one Connection with a - It MUST be possible to associate more than one Connection with a
Call. Call.
- Removal of the last Connection associated with a Call SHOULD NOT - Removal of the last Connection associated with a Call SHOULD NOT
result in the automatic removal of the Call except as a matter of result in the automatic removal of the Call except as a matter of
local policy at the ingress of the Call. local policy at the ingress of the Call.
skipping to change at page 6, line 5 skipping to change at page 6, line 5
A Call may be established and maintained independently of the A Call may be established and maintained independently of the
Connections that it supports. Connections that it supports.
4.2 A Hierarchy of Calls, Connections, Tunnels and LSPs 4.2 A Hierarchy of Calls, Connections, Tunnels and LSPs
Clearly there is a hierarchical relationship between Calls and Clearly there is a hierarchical relationship between Calls and
Connections. One or more Connections may be associated with a Call. A Connections. One or more Connections may be associated with a Call. A
Connection may not be part of more than one Call. A Connection may, Connection may not be part of more than one Call. A Connection may,
however, exist without a Call. however, exist without a Call.
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
In GMPLS RSVP-TE [RFC3473], a Connection is identified with a GMPLS In GMPLS RSVP-TE [RFC3473], a Connection is identified with a GMPLS
TE Tunnel. Commonly a Tunnel is identified with a single LSP, but it TE Tunnel. Commonly a Tunnel is identified with a single LSP, but it
should be noted that for protection, load balancing and many other should be noted that for protection, load balancing and many other
functions, a Tunnel may be supported by multiple parallel LSPs. The functions, a Tunnel may be supported by multiple parallel LSPs. The
following identification reproduces this hierarchy. following identification reproduces this hierarchy.
- Call IDs are unique within the context of the pair of addresses - Call IDs are unique within the context of the pair of addresses
that are the source and destination of the Call. that are the source and destination of the Call.
skipping to change at page 7, line 5 skipping to change at page 7, line 5
bundled based on technology specific attributes. bundled based on technology specific attributes.
In some circumstances, the Traffic Engineering Database (TED) may In some circumstances, the Traffic Engineering Database (TED) may
contain sufficient information for decisions to be made about which contain sufficient information for decisions to be made about which
egress network link to use. In other circumstances, the TED might not egress network link to use. In other circumstances, the TED might not
contain this information and Call setup may provide a suitable contain this information and Call setup may provide a suitable
mechanism to exchange information for this purpose. The mechanism to exchange information for this purpose. The
Call-responder may use the Call parameters to select a subset of the Call-responder may use the Call parameters to select a subset of the
available egress network links between the egress NN and the remote available egress network links between the egress NN and the remote
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
EN, and may report these links and their capabilities on the Call EN, and may report these links and their capabilities on the Call
response so that the Call-initiator may select a suitable link. response so that the Call-initiator may select a suitable link.
The sections that follow indicate the cases where the TED may be The sections that follow indicate the cases where the TED may be
used, and those where Call parameter exchange may be appropriate. used, and those where Call parameter exchange may be appropriate.
4.3.1 Network-initiated Calls 4.3.1 Network-initiated Calls
Network-initiated Calls arise when the ingress (and correspondingly Network-initiated Calls arise when the ingress (and correspondingly
skipping to change at page 8, line 5 skipping to change at page 8, line 5
The Call setup procedure provides an opportunity to discover edge The Call setup procedure provides an opportunity to discover edge
link capabilities of remote edge nodes before LSP setup is attempted. link capabilities of remote edge nodes before LSP setup is attempted.
- The Call-responder can return information on one or more egress - The Call-responder can return information on one or more egress
network links. The Call-reponder could return a full list of the network links. The Call-reponder could return a full list of the
available links with information about the link capabilities, or it available links with information about the link capabilities, or it
could filter the list to return information about only those links could filter the list to return information about only those links
which might be appropriate to support the Connections needed by the which might be appropriate to support the Connections needed by the
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
Call. To do this second option, the Call-responder must determine Call. To do this second option, the Call-responder must determine
such appropriate links from information carried in the Call request such appropriate links from information carried in the Call request
including destination of the Call, and the level of service including destination of the Call, and the level of service
(bandwidth, protection, etc.) required. (bandwidth, protection, etc.) required.
- On receiving a Call response, the Call-initiator must determine - On receiving a Call response, the Call-initiator must determine
paths for the Connections (LSPs) that it will set up. The way that paths for the Connections (LSPs) that it will set up. The way that
it does this is out of scope for this document since it is an it does this is out of scope for this document since it is an
implementation-specific, algorithmic process. However, it can take implementation-specific, algorithmic process. However, it can take
skipping to change at page 9, line 5 skipping to change at page 9, line 5
not be unreasonable. It is not the place of this document to supply not be unreasonable. It is not the place of this document to supply
rules for encoding or parsing Call IDs, but it must provide a rules for encoding or parsing Call IDs, but it must provide a
suitable means to communicate Call IDs within the protocol. The full suitable means to communicate Call IDs within the protocol. The full
Call identification is referred to as the long Call ID. Call identification is referred to as the long Call ID.
The Call_ID is only relevant at the sender and receiver nodes. The Call_ID is only relevant at the sender and receiver nodes.
Maintenance of this information in the signaling state is not Maintenance of this information in the signaling state is not
mandated at any intermediate node. Thus no change in [RFC3473] mandated at any intermediate node. Thus no change in [RFC3473]
transit implementations is required and there are no backward transit implementations is required and there are no backward
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
compatibility issues. Forward compatibility is maintained by using compatibility issues. Forward compatibility is maintained by using
the existing default values to indicate that no Call processing is the existing default values to indicate that no Call processing is
required. required.
Further, the long Call ID is not required as part of the Connection Further, the long Call ID is not required as part of the Connection
(LSP) state even at the sender and receiver nodes so long as some (LSP) state even at the sender and receiver nodes so long as some
form of correlation is available. This correlation is provided form of correlation is available. This correlation is provided
through the short Call ID. through the short Call ID.
skipping to change at page 10, line 5 skipping to change at page 10, line 5
processing to determine the session to which an RSVP signaling processing to determine the session to which an RSVP signaling
message applies. This does not generate any backward compatibility message applies. This does not generate any backward compatibility
issue since the reserved field of the SESSION object defined in issue since the reserved field of the SESSION object defined in
[RFC3209] MUST NOT be examined on receipt. [RFC3209] MUST NOT be examined on receipt.
In the unlikely case of short Call_ID exhaustion, local node policy In the unlikely case of short Call_ID exhaustion, local node policy
decides upon specific actions to be taken, but might include the use decides upon specific actions to be taken, but might include the use
of second Sender_Address. Local policy details are outside of the of second Sender_Address. Local policy details are outside of the
scope of this document. scope of this document.
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
5.2.3 Short Form Call ID Encoding 5.2.3 Short Form Call ID Encoding
The short Call ID is carried in a 16-bit field in the SESSION object The short Call ID is carried in a 16-bit field in the SESSION object
carried on the Notify message used during Call setup, and on all carried on the Notify message used during Call setup, and on all
messages during LSP setup and management. The field used was messages during LSP setup and management. The field used was
previously reserved (MUST be set to zero on transmission and ignored previously reserved (MUST be set to zero on transmission and ignored
on receipt). This ensures backward compatibility with nodes that do on receipt). This ensures backward compatibility with nodes that do
not utilize Calls. not utilize Calls.
skipping to change at page 11, line 5 skipping to change at page 11, line 5
Call-terminating node) to the network. The specific node is indicated Call-terminating node) to the network. The specific node is indicated
by the source address of the Notify message. by the source address of the Notify message.
The link reported can be a single link or can be a bundled link The link reported can be a single link or can be a bundled link
[RFC4201]. [RFC4201].
The Class Number is selected so that the nodes that do not recognize The Class Number is selected so that the nodes that do not recognize
this object drop it silently. That is, the top bit is set and the this object drop it silently. That is, the top bit is set and the
next bit is clear. next bit is clear.
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
This object has the following format: This object has the following format:
Class-Num = TBA (form 10bbbbbb), C_Type = 1 Class-Num = TBA (form 10bbbbbb), C_Type = 1
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (Subobjects) // // (Subobjects) //
skipping to change at page 12, line 5 skipping to change at page 12, line 5
Notify message are not supported by this specification. In the event Notify message are not supported by this specification. In the event
that a Notify message contains multiple LINK_CAPABILITY objects, the that a Notify message contains multiple LINK_CAPABILITY objects, the
receiver SHOULD process the first one as normal and SHOULD ignore receiver SHOULD process the first one as normal and SHOULD ignore
subsequent instances of the object. subsequent instances of the object.
5.4 Revised Message Formats 5.4 Revised Message Formats
The Notify message is enhanced to support Call establishment and The Notify message is enhanced to support Call establishment and
teardown of Calls. See Section 6 for a description of the procedures. teardown of Calls. See Section 6 for a description of the procedures.
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
5.4.1 Notify Message 5.4.1 Notify Message
The Notify message is modified in support of Call establishment by The Notify message is modified in support of Call establishment by
the optional addition of the LINK CAPABILTY object. Further, the the optional addition of the LINK 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 ATTRIBUTE object carry the long Call ID. The presence of the SESSION ATTRIBUTE object
MAY be used to distinguish a Notify message used for Call management, MAY be used to distinguish a Notify message used for Call management,
but see Section 5.5 for another mechanism. The <notify session list> but see Section 5.5 for another mechanism. The <notify session list>
MAY be used to simultaneously set up multiple Calls. MAY be used to simultaneously set up multiple Calls.
skipping to change at page 13, line 5 skipping to change at page 13, line 5
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |C|T|A|D| |R| Reserved |C|T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reflect (R): 1 bit - see [RFC3471] Reflect (R): 1 bit - see [RFC3471]
Testing (T): 1 bit - see [RFC3471] Testing (T): 1 bit - see [RFC3471]
Administratively down (A): 1 bit - see [RFC3471] Administratively down (A): 1 bit - see [RFC3471]
Deletion in progress (D): 1 bit - see [RFC3471] Deletion in progress (D): 1 bit - see [RFC3471]
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
Call Management (C): 1 bit Call Management (C): 1 bit
This bit is set when the message is being used to control This bit is set when the message is being used to control
and manage a Call. and manage a Call.
The procedures for the use of the C bit are described in Section 6. The procedures for the use of the C bit are described in Section 6.
6. Procedures in Support of Calls and Connections 6. Procedures in Support of Calls and Connections
skipping to change at page 14, line 5 skipping to change at page 14, line 5
6.2 Call Setup 6.2 Call Setup
A Call is set up before, and independent of, LSP (i.e. Connection) A Call is set up before, and independent of, LSP (i.e. Connection)
setup. setup.
Call setup MAY necessitate verification of the link status and link Call setup MAY necessitate verification of the link status and link
capability negotiation between the Call ingress node and the Call capability negotiation between the Call ingress node and the Call
egress node. The procedure described below is applied only once for a egress node. The procedure described below is applied only once for a
Call and hence only once for the set of LSPs associated with a Call. Call and hence only once for the set of LSPs associated with a Call.
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
The Notify message (see [RFC3473]) is used to signal the Call setup The Notify message (see [RFC3473]) is used to signal the Call setup
request and response. The new Call Management (C) bit in the request and response. The new Call Management (C) bit in the
ADMIN_STATUS object is used to indicate that this Notify is managing ADMIN_STATUS object is used to indicate that this Notify is managing
a Call. The Notify message is sent with source and destination a Call. The Notify message is sent with source and destination
IPv4/IPv6 addresses set to any of the routable ingress/egress node IPv4/IPv6 addresses set to any of the routable ingress/egress node
addresses respectively. addresses respectively.
At least one session MUST be listed in the <notify session list> of At least one session MUST be listed in the <notify session list> of
the Notify message. In order to allow for long identification of the the Notify message. In order to allow for long identification of the
skipping to change at page 15, line 5 skipping to change at page 15, line 5
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
identify value in assigning priorities to Calls; accordingly the identify value in assigning priorities to Calls; accordingly the
Priority fields MAY be set to non-zero values. None of the Flags Priority fields MAY be set to non-zero values. None of the Flags
in the SESSION ATTRIBUTE object is relevant to this process and in the SESSION ATTRIBUTE object is relevant to this process and
this field SHOULD be set to zero. The Session Name field is used this field SHOULD be set to zero. The Session Name field is used
to carry the long Call Id as described in Section 5. to carry the long Call Id as described in Section 5.
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
- The SENDER_TEMPLATE object includes as Sender Address any of the - The SENDER_TEMPLATE object includes as Sender Address any of the
Call-initiating (ingress) node's IPv4/IPv6 routable addresses. The Call-initiating (ingress) node's IPv4/IPv6 routable addresses. The
LSP_ID is not relevant and SHOULD be set to zero. LSP_ID is not relevant and SHOULD be set to zero.
- The bandwidth value inserted in the SENDER_TSPEC and FLOWSPEC - The bandwidth value inserted in the SENDER_TSPEC and FLOWSPEC
objects MUST be ignored upon receipt and SHOULD be set to zero objects MUST be ignored upon receipt and SHOULD be set to zero
when sent. when sent.
Additionally, ingress/egress nodes that need to communicate their Additionally, ingress/egress nodes that need to communicate their
skipping to change at page 16, line 5 skipping to change at page 16, line 5
- 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 MUST use the Message ID object to ensure reliable The responder MUST use the Message ID object to ensure reliable
delivery of the response. If no Message ID Acknowledgement is delivery of the response. If no Message ID Acknowledgement is
received after the configured number of retries, the responder SHOULD received after the configured number of retries, the responder SHOULD
continue to assume that the Call was successfully established. Call continue to assume that the Call was successfully established. Call
liveliness procedures are covered in Section 6.7. liveliness procedures are covered in Section 6.7.
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
6.2.2 Call Setup Failure and Rejection 6.2.2 Call Setup Failure and Rejection
Call setup may fail or be rejected. Call setup may fail or be rejected.
If the Notify message can not be delivered, no Message ID If the Notify message can not be delivered, no Message ID
acknowledgement will be received by the sender. In the event that the acknowledgement will be received by the sender. In the event that the
sender has retransmitted the Notify message a configurable number of sender has retransmitted the Notify message a configurable number of
times without receiving a Message ID Acknowledgement (as described in times without receiving a Message ID Acknowledgement (as described in
[RFC2961]), the initiator SHOULD declare the Call failed and SHOULD [RFC2961]), the initiator SHOULD declare the Call failed and SHOULD
skipping to change at page 17, line 5 skipping to change at page 17, line 5
There will be no confusion between LSPs that are associated with a There will be no confusion between LSPs that are associated with a
Call and those which are not, since the Call ID value MUST be equal Call and those which are not, since the Call ID value MUST be equal
to zero for LSPs which are not associated with a Call, and MUST NOT to zero for LSPs which are not associated with a Call, and MUST NOT
be equal to zero for a valid Call ID. be equal to zero for a valid Call ID.
LSPs for different Calls can be distinguished because the Call ID is LSPs for different Calls can be distinguished because the Call ID is
unique within the context of the source address (in the SENDER unique within the context of the source address (in the SENDER
TEMPLATE object) and the destination address (in the SESSION object). TEMPLATE object) and the destination address (in the SESSION object).
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
Ingress and egress nodes MAY group together LSPs associated with the Ingress and egress nodes MAY group together LSPs associated with the
same Call and process them as a group according to implementation same Call and process them as a group according to implementation
requirements. Transit nodes need not be aware of the association of requirements. Transit nodes need not be aware of the association of
multiple LSPs with the same Call. multiple LSPs with the same Call.
The ingress node MAY choose to set the "Session Name" of an LSP to The ingress node MAY choose to set the "Session Name" of an LSP to
match the long Call ID of the associated Call. match the long Call ID of the associated Call.
The C bit of the ADMIN STATUS object MUST NOT be set on LSP messages The C bit of the ADMIN STATUS object MUST NOT be set on LSP messages
skipping to change at page 18, line 5 skipping to change at page 18, line 5
Since Calls are symmetrical, it is possible that both ends of a Call Since Calls are symmetrical, it is possible that both ends of a Call
will attempt to establish Calls with the same long Call IDs at the will attempt to establish Calls with the same long Call IDs at the
same time. This is only an issue if the source and destination same time. This is only an issue if the source and destination
address pairs match. This situation can be avoided by applying some address pairs match. This situation can be avoided by applying some
rules to the contents of the long Call ID, but such mechanisms are rules to the contents of the long Call ID, but such mechanisms are
outside the scope of this document. outside the scope of this document.
If a node that has sent a Call setup request and has not yet received If a node that has sent a Call setup request and has not yet received
a response, itself receives a Call setup request with the same long a response, itself receives a Call setup request with the same long
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
Call ID and matching source/destination addresses, it SHOULD process Call ID and matching source/destination addresses, it SHOULD process
as follows. as follows.
- If its source address is numerically greater than the remote - If its source address is numerically greater than the remote
source address, it MUST discard the received message and continue source address, it MUST discard the received message and continue
to wait for a response to its setup request. to wait for a response to its setup request.
- If its source address is numerically smaller than the remote - If its source address is numerically smaller than the remote
source address, it MUST discard state associated with the Call source address, it MUST discard state associated with the Call
skipping to change at page 19, line 5 skipping to change at page 19, line 5
As with Call/Connection setup, there are several cases to consider. As with Call/Connection setup, there are several cases to consider.
- Removal of a Connection from a Call - Removal of a Connection from a Call
- Removal of the last Connection from a Call - Removal of the last Connection from a Call
- Teardown of an "empty" Call - Teardown of an "empty" Call
The case of tearing down an LSP that is not associated with a Call The case of tearing down an LSP that is not associated with a Call
does not need to be examined as it follows exactly the procedures does not need to be examined as it follows exactly the procedures
described in [RFC3473]. described in [RFC3473].
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
6.6.1 Removal of a Connection from a Call 6.6.1 Removal of a Connection from a Call
An LSP that is associated with a Call may be deleted using the An LSP that is associated with a Call may be deleted using the
standard procedures described in [RFC3473]. No special procedures are standard procedures described in [RFC3473]. No special procedures 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
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,
skipping to change at page 20, line 5 skipping to change at page 20, line 5
circumstances the node SHOULD avoid re-using the long or short Call circumstances the node SHOULD avoid re-using the long or short Call
IDs for at least five times the Notify refresh period. IDs for at least five times the Notify refresh period.
6.6.4 Attempted Teardown of a Call with Existing Connections 6.6.4 Attempted Teardown of a Call with Existing Connections
If a Notify request with the D bit of the ADMIN STATUS object set is If a Notify request with the D bit of the ADMIN STATUS object set is
received for a Call for which LSPs still exist, the request MUST be received for a Call for which LSPs still exist, the request MUST be
rejected with the Error Code "Call Management" and Error Value rejected with the Error Code "Call Management" and Error Value
"Connections Still Exist". The state of the Call MUST NOT be changed. "Connections Still Exist". The state of the Call MUST NOT be changed.
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
6.6.5 Teardown of a Call from the Egress 6.6.5 Teardown of a Call from the Egress
Since Calls are symmetric they may be torn down from the ingress or Since Calls are symmetric they may be torn down from the ingress or
egress. egress.
When the Call is "empty" (has no associated LSPs) it may be deleted When the Call is "empty" (has no associated LSPs) it may be deleted
by the egress sending a Notify message just as described above. by the egress sending a Notify message just as described above.
Note that there is a possibility that both ends of a Call initiate Note that there is a possibility that both ends of a Call initiate
skipping to change at page 21, line 5 skipping to change at page 21, line 5
may have changed since the Call was first established, due to, e.g., may have changed since the Call was first established, due to, e.g.,
the establishment of Connections, link failures, or the addition of the establishment of Connections, link failures, or the addition of
new component links. The current link information is useful for the new component links. The current link information is useful for the
establishment of subsequent Connections. A node that receives a establishment of subsequent Connections. A node that receives a
refresh Notify message carrying the R bit in the ADMIN STATUS object refresh Notify message carrying the R bit in the ADMIN STATUS object
MUST respond with a Notify response. A node that receives a refresh MUST respond with a Notify response. A node that receives a refresh
Notify message (response or request) MAY reset its timer - thus, in Notify message (response or request) MAY reset its timer - thus, in
normal processing, Notify refreshes involve a single exchange once normal processing, Notify refreshes involve a single exchange once
per time period. per time period.
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
A node (sender or receiver) that is unsure of the status of a Call A node (sender or receiver) that is unsure of the status of a Call
MAY immediately send a Notify message as if establishing the Call for MAY immediately send a Notify message as if establishing the Call for
the first time. the first time.
Failure to receive a refresh Notify request has no specific meaning. Failure to receive a refresh Notify request has no specific meaning.
A node that fails to receive a refresh Notify request MAY send its A node that fails to receive a refresh Notify request MAY send its
own refresh Notify request to establish the status of the Call. If a own refresh Notify request to establish the status of the Call. If a
node receives no response to a refresh Notify request (including no node receives no response to a refresh Notify request (including no
Message ID Acknowledgement) a node MAY assume that the remote node is Message ID Acknowledgement) a node MAY assume that the remote node is
skipping to change at page 22, line 5 skipping to change at page 22, line 5
domains do not share this sort of information. In this case, the Call domains do not share this sort of information. In this case, the Call
setup mechanism may include the LINK_CAPABILITY object. setup mechanism may include the LINK_CAPABILITY object.
7.2 User-initiated Calls 7.2 User-initiated Calls
It is possible that the access link properties and other traffic- It is possible that the access link properties and other traffic-
engineering attributes are not shared across the core network. In engineering attributes are not shared across the core network. In
this case, the Call setup mechanism may include the LINK_CAPABILITY this case, the Call setup mechanism may include the LINK_CAPABILITY
object. object.
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
Further, the first node within the network may be responsible for Further, the first node within the network may be responsible for
managing the Call. In this case, the Notify message that is used to managing the Call. In this case, the Notify message that is used to
set up the Call is addressed by the user network edge node to the set up the Call is addressed by the user network edge node to the
first node of the core network. Moreover, neither the long Call ID first node of the core network. Moreover, neither the long Call ID
nor the short Call ID is supplied (the Session Name Length is set to nor the short Call ID is supplied (the Session Name Length is set to
zero and the Call ID value is set to zero). The Notify message is zero and the Call ID value is set to zero). The Notify message is
passed to the first network node which is responsible for generating passed to the first network node which is responsible for generating
the long and short Call IDs before dispatching the message to the the long and short Call IDs before dispatching the message to the
remote Call end point (which is known from the SESSION object). remote Call end point (which is known from the SESSION object).
skipping to change at page 23, line 5 skipping to change at page 23, line 5
used to identify the Call (the Sender Address in the SENDER TEMPLATE used to identify the Call (the Sender Address in the SENDER TEMPLATE
object and the Tunnel Endpoint Address in the SESSION object) object and the Tunnel Endpoint Address in the SESSION object)
continue to identify the endpoints of the Call. continue to identify the endpoints of the Call.
8. Non-support of Call ID 8. Non-support of Call ID
It is important that the procedures described above operate as It is important that the procedures described above operate as
seamlessly as possible with legacy nodes that do not support the seamlessly as possible with legacy nodes that do not support the
extensions described. extensions described.
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
Clearly, there is no need to consider the case where the Call Clearly, there is no need to consider the case where the Call
initiator does not support Call setup initiation. initiator does not support Call setup initiation.
8.1 Non-Support by External Call Managers 8.1 Non-Support by External Call Managers
It is unlikely that a Call initiator will be configured to send Call It is unlikely that a Call initiator will be configured to send Call
establishment Notify requests to an external Call manager, including establishment Notify requests to an external Call manager, including
the first network node, if that node does not support Call setup. the first network node, if that node does not support Call setup.
skipping to change at page 24, line 5 skipping to change at page 24, line 5
some implementations as meaning that the fields should be zeroed some implementations as meaning that the fields should be zeroed
before the objects are forwarded. If this happens, LSP setup will not before the objects are forwarded. If this happens, LSP setup will not
be possible. If either of the fields is zeroed either on the Path or be possible. If either of the fields is zeroed either on the Path or
the Resv message, the Resv message will reach the initiator with the the Resv message, the Resv message will reach the initiator with the
field set to zero - this is indication to the initiator that some field set to zero - this is indication to the initiator that some
node in the network is preventing Call management. Use of Explicit node in the network is preventing Call management. Use of Explicit
Routes may help to mitigate this issue by avoiding such nodes. Routes may help to mitigate this issue by avoiding such nodes.
Ultimately, however, it may be necessary to upgrade the offending Ultimately, however, it may be necessary to upgrade the offending
nodes to handle these protocol extensions. nodes to handle these protocol extensions.
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
8.3 Non-Support by Egress Node 8.3 Non-Support by Egress Node
It is unlikely that an attempt will be made to set up a Call to It is unlikely that an attempt will be made to set up a Call to
remote node that does not support Calls. remote node that does not support Calls.
If the egress node does not support Call management through the If the egress node does not support Call management through the
Notify message it will react (as described in Section 8.1) in the Notify message it will react (as described in Section 8.1) in the
same way as an External Call Manager. same way as an External Call Manager.
skipping to change at page 24, line 32 skipping to change at page 24, line 32
9.1 Call and Connection Security Considerations 9.1 Call and Connection Security Considerations
Call setup is vulnerable to attacks both of spoofing and denial of Call setup is vulnerable to attacks both of spoofing and denial of
service. Since Call setup uses Notify messages, the process can be service. Since Call setup uses Notify messages, the process can be
protected by the use of the Integrity object to secure those messages protected by the use of the Integrity object to secure those messages
as described in [RFC2205] and [RFC3473]. Deployments where as described in [RFC2205] and [RFC3473]. Deployments where
security is a concern SHOULD use this mechanism. security is a concern SHOULD use this mechanism.
Implementations and deployments MAY additionally protect the Implementations and deployments MAY additionally protect the
Call setup exchange using end-to-end security mechanisms such as Call setup exchange using end-to-end security mechanisms such as
those provided by IPsec (see [RFC2402] and [RFC2406]), or using RSVP those provided by IPsec (see [RFC4302] and [RFC4303]), or using RSVP
security [RFC2747]. security [RFC2747].
Note, additionally, that the process of independent Call Note, additionally, that the process of independent Call
establishment, where the Call is set up separately from the LSPs, may establishment, where the Call is set up separately from the LSPs, may
be used to apply an extra level of authentication and policy for the be used to apply an extra level of authentication and policy for the
end-to-end LSPs above that which is available with Call-less, end-to-end LSPs above that which is available with Call-less,
hop-by-hop LSP setup. hop-by-hop LSP setup.
The frequency of Call establishment is application dependent and hard The frequency of Call establishment is application dependent and hard
to generalize. Key exchange for Call-related message exchanges is to generalize. Key exchange for Call-related message exchanges is
therefore something that should be configured or arranged dynamically therefore something that should be configured or arranged dynamically
in different deployments according to the advice in [RFC4107]. Note in different deployments according to the advice in [RFC4107]. Note
that the remote RSVP-TE signaling relationship between Call endpoints that the remote RSVP-TE signaling relationship between Call endpoints
is no different from the signaling relationship between LSRs that is no different from the signaling relationship between LSRs that
establish an LSP. That is, the LSRs are not necessarily IP-adjacent establish an LSP. That is, the LSRs are not necessarily IP-adjacent
in the control plane in either case. Thus key exchange should be in the control plane in either case. Thus key exchange should be
regarded as a remote procedure, not a single hop procedure. There are regarded as a remote procedure, not a single hop procedure. There are
several procedures for automatic remote exchange of keys, and IKEv2 several procedures for automatic remote exchange of keys, and IKEv2
[RFC4306] is particularly suggested in [RFC3473]. [RFC4306] is particularly suggested in [RFC3473].
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel January 2007
10. IANA Considerations 10. IANA Considerations
10.1 RSVP Objects 10.1 RSVP Objects
A new RSVP object is introduced. IANA is requested to make an A new RSVP object is introduced. IANA is requested to make an
assignment from the "RSVP Parameters" registry using the sub-registry assignment from the "RSVP Parameters" registry using the sub-registry
"Class Names, Class Numbers, and Class Types". "Class Names, Class Numbers, and Class Types".
o LINK_CAPABILITY object o LINK_CAPABILITY object
skipping to change at page 25, line 30 skipping to change at page 25, line 30
this object drop it silently. That is, the top bit is set this object drop it silently. That is, the top bit is set
and the next bit is cleared. and the next bit is cleared.
C-Type = 1 (TE Link Capabilities) C-Type = 1 (TE Link Capabilities)
The LINK_CAPABILITY object is only defined for inclusion on Notify The LINK_CAPABILITY object is only defined for inclusion on Notify
messages. messages.
Refer to Section 5.3 of this document. Refer to Section 5.3 of this document.
IANA is requested to maintain a list of subobjects that may be
carried in this object. This list should be maintained in the
registry entry for the LINK_CAPABILITY object as is common
practice for the subobjects of other RSVP objects. For each
subobject, IANA should list:
- subobject type number
- subobject name
- reference indicating where subobject is defined.
The initial list of subobjects is provided in Section 5.3 of this
document.
10.2 RSVP Error Codes and Error Values 10.2 RSVP Error Codes and Error Values
A new RSVP Error Code and new Error Values are introduced. IANA is A new RSVP Error Code and new Error Values are introduced. IANA is
requested to make assignments from the "RSVP Parameters" registry requested to make assignments from the "RSVP Parameters" registry
using the sub-registry "Error Codes and Globally-Defined Error using the sub-registry "Error Codes and Globally-Defined Error
Value Sub-Codes". Value Sub-Codes".
o Error Codes: o Error Codes:
- Call Management (value TBA - suggested value 32) - Call Management (value TBA - suggested value 32)
o Error Values: o Error Values:
- Call Management/Call ID Contention (value TBA- suggested 1) - Call Management/Call ID Contention (value TBA- suggested 1)
- Call Management/Connections still Exist (value TBA- suggested 2) - Call Management/Connections still Exist (value TBA- suggested 2)
- Call Management/Unknown Call ID (value TBA- suggested 3) - Call Management/Unknown Call ID (value TBA- suggested 3)
- Call Management/Duplicate Call (value TBA- suggested 4) - Call Management/Duplicate Call (value TBA- suggested 4)
Papadimitriou and Farrel January 2007
10.3 RSVP ADMIN_STATUS object Bits 10.3 RSVP ADMIN_STATUS object Bits
[GMPLS-E2E] requests IANA to manage the bits of the RSVP ADMIN_STATUS [GMPLS-E2E] requests IANA to manage the bits of the RSVP ADMIN_STATUS
object. A new "Administrative Status Information Flags" sub-registry object. A new "Administrative Status Information Flags" sub-registry
of the "GMPLS Signaling Parameters" registry is created. of the "GMPLS Signaling Parameters" registry is created.
This document defines one new bit, the C bit, to be tracked in that This document defines one new bit, the C bit, to be tracked in that
sub-registry. Bit number 28 is suggested. See Section 5.5 of this sub-registry. Bit number 28 is suggested. See Section 5.5 of this
document. document.
Papadimitriou and Farrel - Expires February 2007 January 2007
11. Acknowledgements 11. Acknowledgements
The authors would like to thank George Swallow, Yakov Rekhter, The authors would like to thank George Swallow, Yakov Rekhter,
Lou Berger, Jerry Ash and Kireeti Kompella for their very useful Lou Berger, Jerry Ash and Kireeti Kompella for their very useful
input to, and comments on, an earlier revision of this document. input to, and comments on, an earlier revision of this document.
Thanks to Lyndon Ong and Ben Mack-Crane for lengthy discussions Thanks to Lyndon Ong and Ben Mack-Crane for lengthy discussions
during and after working group last call, and to Deborah Brungard for during and after working group last call, and to Deborah Brungard for
a final, detailed review. a final, detailed review.
Thanks to Suresh Krishnan for the GenArt review, and to Magnus Thanks to Suresh Krishnan for the GenArt review, and to Magnus
Nystrom for discussions about security. Nystrom for discussions about security.
Useful comments were received during IESG review from Brian
Carpenter, Lars Eggert, Ted Hardie, Russ Housley,
12. References 12. References
12.1 Normative References 12.1 Normative References
[GMPLS-E2E] Lang, J.P., Rekhter, Y., and D. Papadimitriou, "RSVP- [GMPLS-E2E] Lang, J.P., Rekhter, Y., and D. Papadimitriou, "RSVP-
TE Extensions in support of End-to-End Generalized TE Extensions in support of End-to-End Generalized
Multi-Protocol Label Switching (GMPLS)-based Recovery," Multi-Protocol Label Switching (GMPLS)-based Recovery,"
draft-ietf-ccamp-gmpls-recovery-e2e-signaling, work in draft-ietf-ccamp-gmpls-recovery-e2e-signaling, work in
progress. progress.
[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, March 1997. Requirement Levels," BCP 14, RFC 2119, March 1997.
[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, September 1997. RFC 2205, September 1997.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header,"
RFC 2402, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Payload
(ESP)," RFC 2406, November 1998.
[RFC2747] Baker, F., Lindell, B. and M. Talwar, "RSVP [RFC2747] Baker, F., Lindell, B. and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January Cryptographic Authentication", RFC 2747, January
2000. 2000.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi,
F. and S. Molendini, "RSVP Refresh Overhead F. and S. Molendini, "RSVP Refresh Overhead
Reduction Extensions", RFC 2961, April 2001. Reduction Extensions", RFC 2961, April 2001.
Papadimitriou and Farrel January 2007
[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, December 2001. LSP Tunnels," RFC 3209, December 2001.
[RFC3471] L. Berger (Editor) et al., "Generalized MPLS - [RFC3471] L. Berger (Editor) et al., "Generalized MPLS -
Signaling Functional Description," RFC 3471, January Signaling Functional Description," RFC 3471, January
2003. 2003.
Papadimitriou and Farrel - Expires February 2007 January 2007
[RFC3473] L. Berger (Editor) et al., "Generalized MPLS Signaling [RFC3473] L. Berger (Editor) et al., "Generalized MPLS Signaling
- RSVP-TE Extensions," RFC 3473, January 2003. - RSVP-TE Extensions," RFC 3473, January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered
Links in Resource ReSerVation Protocol - Traffic Links in Resource ReSerVation Protocol - Traffic
Engineering (RSVP-TE)," RFC 3477, January 2003. Engineering (RSVP-TE)," RFC 3477, January 2003.
[RFC3945] E. Mannie, Ed., "Generalized Multi-Protocol Label [RFC3945] E. Mannie, Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October Switching (GMPLS) Architecture", RFC 3945, October
2004. 2004.
[RFC4139] D. Papadimitriou, et al., "Requirements for Generalized
MPLS (GMPLS) Signaling Usage and Extensions for
Automatically Switched Optical Network (ASON)," RFC
4139, July 2005.
[RFC4201] Kompella K., Rekhter Y., and L. Berger, "Link Bundling [RFC4201] Kompella K., Rekhter Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering," RFC 4201, October 2005. in MPLS Traffic Engineering," RFC 4201, October 2005.
[RFC4202] Kompella, K. and Y. Rekhter (Editors) et al., "Routing [RFC4202] Kompella, K. and Y. Rekhter (Editors) et al., "Routing
Extensions in Support of Generalized MPLS," RFC 4202, Extensions in Support of Generalized MPLS," RFC 4202,
October 2005. October 2005.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter, Y. [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter, Y.
"Generalized Multiprotocol Label Switching (GMPLS) "Generalized Multiprotocol Label Switching (GMPLS)
User-Network Interface (UNI): Resource ReserVation User-Network Interface (UNI): Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Support for the Protocol-Traffic Engineering (RSVP-TE) Support for the
Overlay Model", RFC 4208, October 2005. Overlay Model", RFC 4208, October 2005.
[RFC4302] Kent, S., "IP Authentication Header," RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Payload (ESP)," RFC 4303,
December 2005.
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005. Protocol", RFC 4306, December 2005.
[RFC4426] Lang, J.P., and B. Rajagopalan (Editors) et al., [RFC4426] Lang, J.P., and B. Rajagopalan (Editors) et al.,
"Generalized MPLS Recovery Functional "Generalized MPLS Recovery Functional
Specification," RFC 4426, March 2006. Specification," RFC 4426, March 2006.
12.2 Informative References 12.2 Informative References
[ASON-APPL] D. Papadimitriou et. al., "Generalized MPLS (GMPLS) [ASON-APPL] D. Papadimitriou et. al., "Generalized MPLS (GMPLS)
RSVP-TE signaling usage in support of Automatically RSVP-TE signaling usage in support of Automatically
Switched Optical Network (ASON)," Switched Optical Network (ASON),"
draft-ietf-ccamp-gmpls-rsvp-te-ason, work in progress. draft-ietf-ccamp-gmpls-rsvp-te-ason, work in progress.
Papadimitriou and Farrel January 2007
[RFC4107] S. Bellovin and R. Housley, "Guidelines for Cryptographic [RFC4107] S. Bellovin and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005. Key Management", BCP 107, RFC 4107, June 2005.
[RFC4139] D. Papadimitriou, et al., "Requirements for Generalized
MPLS (GMPLS) Signaling Usage and Extensions for
Automatically Switched Optical Network (ASON)," RFC
4139, July 2005.
[STITCH] Ayyangar, A., Kompella, K., and Vasseur, JP., "Label [STITCH] Ayyangar, A., Kompella, K., and Vasseur, JP., "Label
Switched Path Stitching with Generalized MPLS Traffic Switched Path Stitching with Generalized MPLS Traffic
Engineering", draft-ietf-ccamp-lsp-stitching, work in Engineering", draft-ietf-ccamp-lsp-stitching, work in
progress. progress.
Papadimitriou and Farrel - Expires February 2007 January 2007
For information on the availability of the following document, For information on the availability of the following document,
please see http://www.itu.int. please see http://www.itu.int.
[G.8080] ITU-T, "Architecture for the Automatically Switched [G.8080] ITU-T, "Architecture for the Automatically Switched
Optical Network (ASON)," Recommendation G.8080/ Optical Network (ASON)," Recommendation G.8080/
Y.1304, November 2001 (and Revision, January 2003). Y.1304, November 2001 (and Revision, January 2003).
13. Contact Addresses 13. Contact Addresses
Dimitri Papadimitriou Dimitri Papadimitriou
skipping to change at page 28, line 41 skipping to change at page 29, line 5
Boeing Satellite Systems Boeing Satellite Systems
2300 East Imperial Highway 2300 East Imperial Highway
El Segundo, CA 90245 El Segundo, CA 90245
EMail: John.E.Drake2@boeing.com EMail: John.E.Drake2@boeing.com
Deborah Brungard (AT&T) Deborah Brungard (AT&T)
Rm. D1-3C22 - 200 S. Laurel Ave. Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ 07748, USA Middletown, NJ 07748, USA
EMail: dbrungard@att.com EMail: dbrungard@att.com
Papadimitriou and Farrel January 2007
Zafar Ali (Cisco) Zafar Ali (Cisco)
100 South Main St. #200 100 South Main St. #200
Ann Arbor, MI 48104, USA Ann Arbor, MI 48104, USA
EMail: zali@cisco.com EMail: zali@cisco.com
Arthi Ayyangar (Nuova Systems) Arthi Ayyangar (Nuova Systems)
2600 San Tomas Expressway 2600 San Tomas Expressway
Santa Clara, CA 95051 Santa Clara, CA 95051
EMail: arthi@nuovasystems.com EMail: arthi@nuovasystems.com
Don Fedyk (Nortel Networks) Don Fedyk (Nortel Networks)
600 Technology Park Drive 600 Technology Park Drive
Billerica, MA, 01821, USA Billerica, MA, 01821, USA
Email: dwfedyk@nortel.com Email: dwfedyk@nortel.com
Papadimitriou and Farrel - Expires February 2007 January 2007
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
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 29, line 41 skipping to change at page 30, line 5
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Papadimitriou and Farrel January 2007
Copyright Statement Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
 End of changes. 44 change blocks. 
48 lines changed or deleted 63 lines changed or added

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