draft-ietf-ccamp-gmpls-rsvp-te-call-02.txt   draft-ietf-ccamp-gmpls-rsvp-te-call-03.txt 
CCAMP 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-02.txt draft-ietf-ccamp-gmpls-rsvp-te-call-03.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 3, line 45 skipping to change at page 3, line 45
A Call is an association between endpoints and possibly between key A Call is an association between endpoints and possibly between key
transit points (such as network boundaries) in support of an instance transit points (such as network boundaries) in support of an instance
of a service. The end-to-end association is termed a "Call," and the of a service. The end-to-end association is termed a "Call," and the
association between two transit points or between an endpoint and a association between two transit points or between an endpoint and a
transit point is termed a "Call Segment." An entity that processes a transit point is termed a "Call Segment." An entity that processes a
Call or Call Segment is called a "Call Manager." Call or Call Segment is called a "Call Manager."
A Call does not provide the actual connectivity for transmitting user A Call does not provide the actual connectivity for transmitting user
traffic, but only builds a relationship by which subsequent traffic, but only builds a relationship by which subsequent
Connections may be made. In GMPLS such Connections are known as Label Connections may be made. In GMPLS such Connections are known as Label
Switched Paths (LSPs). Switched Paths (LSPs). This document does not modify Connection setup
procedures defined in [RFC3473], [RFC4208] and [STITCH]. Connections
set up as part of a Call follow the rules defined in these documents.
A Call may be associated with zero, one, or more than one Connection, A Call may be associated with zero, one, or more than one Connection,
and a Connection may be associated with zero or one Call. Thus full and a Connection may be associated with zero or one Call. Thus full
and logical Call/Connection separation is needed. and logical Call/Connection separation is needed.
An example of the requirement for Calls can be found in the ITU-T's An example of the 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
described in this document meet the requirements stated in [RFC4139],
they have wider applicability.
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel - Expires February 2007 January 2007
described in this document meet the requirements stated in [RFC4139],
they have wider applicability.
The mechanisms defined in this document are equally applicable to any The mechanisms defined in this document are equally applicable to any
packet (PSC) interface, layer-2 interfaces (L2SC), TDM capable packet (PSC) interface, layer-2 interfaces (L2SC), TDM capable
interfaces, LSC interfaces, or FSC interfaces. The mechanisms and interfaces, LSC interfaces, or FSC interfaces. The mechanisms and
protocol extensions are backward compatible, and can be used for Call protocol extensions are backward compatible, and can be used for Call
management where only the Call Managers need to be aware of the management where only the Call Managers need to be aware of the
protocol extensions. protocol extensions.
2.1 Applicability to ASON 2.1 Applicability to ASON
[RFC4139] details the requirements on GMPLS signaling to satisfy the [RFC4139] details the requirements on GMPLS signaling to satisfy the
skipping to change at page 4, line 53 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
- It MUST be possible to establish a Call without any associated - It MUST be possible to establish a Call without any associated
Connections. Connections.
Papadimitriou and Farrel - Expires February 2007 January 2007
- It MUST be possible to associate more than one Connection with a - It MUST be possible to associate more than one Connection with a
Call. Call.
- Removal of the last Connection associated with a Call SHOULD NOT - Removal of the last Connection associated with a Call SHOULD NOT
result in the automatic removal of the Call except as a matter of result in the automatic removal of the Call except as a matter of
local policy at the ingress of the Call. local policy at the ingress of the Call.
- Signaling of a Connection associated with a Call MUST NOT require - Signaling of a Connection associated with a Call MUST NOT require
the distribution or retention of Call-related information (state) the distribution or retention of Call-related information (state)
within the network. within the network.
skipping to change at page 5, line 55 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.
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
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel - Expires February 2007 January 2007
In GMPLS RSVP-TE [RFC3473], a Connection is identified with a GMPLS
TE Tunnel. Commonly a Tunnel is identified with a single LSP, but it
should be noted that for protection, load balancing and many other 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.
- Tunnel IDs are unique within the context of the Session (that is - Tunnel IDs are unique within the context of the Session (that is
the destination of the Tunnel). Applications may also find it the destination of the Tunnel). Applications may also find it
convenient to keep the Tunnel ID unique within the context of a convenient to keep the Tunnel ID unique within the context of a
skipping to change at page 6, line 55 skipping to change at page 7, line 4
(i.e., spatial attribute negotiation) where TE links have been (i.e., spatial attribute negotiation) where TE links have been
bundled based on technology specific attributes. bundled based on technology specific attributes.
In some circumstances, the Traffic Engineering Database (TED) may In some circumstances, the Traffic Engineering Database (TED) may
contain sufficient information for decisions to be made about which contain sufficient information for decisions to be made about which
egress network link to use. In other circumstances, the TED might not egress network link to use. In other circumstances, the TED might 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
EN, and may report these links and their capabilities on the Call
response so that the Call-initiator may select a suitable link.
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel - Expires February 2007 January 2007
EN, and may report these links and their capabilities on the Call
response so that the Call-initiator may select a suitable link.
The sections that follow indicate the cases where the TED may be The sections that follow indicate the cases where the TED may be
used, and those where Call parameter exchange may be appropriate. used, and those where Call parameter exchange may be appropriate.
4.3.1 Network-initiated Calls 4.3.1 Network-initiated Calls
Network-initiated Calls arise when the ingress (and correspondingly Network-initiated Calls arise when the ingress (and correspondingly
the egress) lie within the network and there may be no need to the egress) lie within the network and there may be no need to
distribute additional link capability information over and above the distribute additional link capability information over and above the
information distributed by the TE and GMPLS extensions to the IGP. information distributed by the TE and GMPLS extensions to the IGP.
Further, it is possible that future extensions to these IGPs will Further, it is possible that future extensions to these IGPs will
skipping to change at page 7, line 54 skipping to change at page 8, line 4
edge nodes, the knowledge of the remote edge link capabilities. edge nodes, the knowledge of the remote edge link capabilities.
The Call setup procedure provides an opportunity to discover edge The Call setup procedure provides an opportunity to discover edge
link capabilities of remote edge nodes before LSP setup is attempted. link capabilities of remote edge nodes before LSP setup is attempted.
- 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
Call. To do this second option, the Call-responder must determine
such appropriate links from information carried in the Call request
including destination of the Call, and the level of service
Papadimitriou and Farrel - Expires February 2007 January 2007 Papadimitriou and Farrel - Expires February 2007 January 2007
Call. To do this second option, the Call-responder must determine
such appropriate links from information carried in the Call request
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
as input the information about the available egress network links as input the information about the available egress network links
as supplied in the Call response. as supplied in the Call response.
The LINK_CAPABILITY object is defined to allow this information to be The LINK_CAPABILITY object is defined to allow this information to be
skipping to change at page 8, line 54 skipping to change at page 9, line 4
considerable (but not arbitrary) length. A Call ID of 40 bytes would considerable (but not arbitrary) length. A Call ID of 40 bytes would
not be unreasonable. It is not the place of this document to supply not be unreasonable. It is not the place of this document to supply
rules for encoding or parsing Call IDs, but it must provide a rules for encoding or parsing Call IDs, but it must provide a
suitable means to communicate Call IDs within the protocol. The full suitable means to communicate Call IDs within the protocol. The full
Call identification is referred to as the long Call ID. Call identification is referred to as the long Call ID.
The Call_ID is only relevant at the sender and receiver nodes. The Call_ID is only relevant at the sender and receiver nodes.
Maintenance of this information in the signaling state is not Maintenance of this information in the signaling state is not
mandated at any intermediate node. Thus no change in [RFC3473] mandated at any intermediate node. Thus no change in [RFC3473]
transit implementations is required and there are no backward transit implementations is required and there are no backward
Papadimitriou and Farrel - Expires February 2007 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.
Papadimitriou and Farrel - Expires February 2007 January 2007
Further, the long Call ID is not required as part of the Connection Further, the long Call ID is not required as part of the Connection
(LSP) state even at the sender and receiver nodes so long as some (LSP) state even at the sender and receiver nodes so long as some
form of correlation is available. This correlation is provided form of correlation is available. This correlation is provided
through the short Call ID. through the short Call ID.
5.2.1 Long Form Call Identification 5.2.1 Long Form Call Identification
The long Call ID is only required on the Notify message used to The long Call ID is only required on the Notify message used to
establish the Call. It is carried in the "Session Name" field of the establish the Call. It is carried in the "Session Name" field of the
SESSION_ATTRIBUTE Object on the Notify message. SESSION_ATTRIBUTE Object on the Notify message.
skipping to change at page 9, line 51 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
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
Papadimitriou and Farrel - Expires February 2007 January 2007
on receipt). This ensures backward compatibility with nodes that do on receipt). This ensures backward compatibility with nodes that do
not utilize Calls. not utilize Calls.
The figure below shows the new version of the object. The figure below shows the new version of the object.
Class = SESSION, Class-Num = 1, C-Type = 7(IPv4)/8(IPv6) Class = SESSION, Class-Num = 1, C-Type = 7(IPv4)/8(IPv6)
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 27, line 50 skipping to change at page 27, line 50
"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.
[RFC4107] S. Bellovin and R. Housley, "Guidelines for [RFC4107] S. Bellovin and R. Housley, "Guidelines for Cryptographic
Cryptographic Key Management", BCP 107, RFC 4107, June Key Management", BCP 107, RFC 4107, June 2005.
2005.
[STITCH] Ayyangar, A., Kompella, K., and Vasseur, JP., "Label
Switched Path Stitching with Generalized MPLS Traffic
Engineering", draft-ietf-ccamp-lsp-stitching, work in
progress.
Papadimitriou and Farrel - Expires February 2007 January 2007 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).
 End of changes. 18 change blocks. 
23 lines changed or deleted 30 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/