|
Dear friends,
We just uploaded a new ID
(draft-zhang-ccamp-gmpls-call-extensions-00), and the following is the abstract
of this new ID.
Please check out the attached document for
details.
We would welcome any comments.
=========================================================================
Abstract:
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extensions are used to support Calls. Although it is stated that these mechanisms are applicable to any environment (including multi-area), the "Call Path" is determined hop-by-hop by each "Call Manager" in sequence along the path of the Call. However, it is desirable to allow the Call-initiator to identify the Call Path explicitly in some cases (especially in the multi-domain case). This document describes RSVP-TE signaling extensions to allow the Call-initiator to identify the Call Path explicitly when transit nodes (besides the Call-initiator and Call-terminator) are involved in these Calls. Thanks Fatai Advanced Technology Department Wireline Networking Business Unit Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935
|
Network work group Fatai Zhang
Internet Draft Dan Li
Intended status: Standards Track Jianhua Gao
Expires: September 2009 Huawei
March 02, 2009
RSVP-TE extensions to GMPLS Calls
draft-zhang-ccamp-gmpls-call-extensions-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
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.
This Internet-Draft will expire on September 02, 2009.
Abstract
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource
ReserVation Protocol-Traffic Engineering (RSVP-TE) extensions are
used to support Calls. Although it is stated that these mechanisms
are applicable to any environment (including multi-area), the "Call
Path" is determined hop-by-hop by each "Call Manager" in sequence
along the path of the Call.
<Zhang> Expires September 02, 2009 [Page 1]
Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009
However, it is desirable to allow the Call-initiator to identify the
Call Path explicitly in some cases (especially in the multi-domain
case).
This document describes RSVP-TE signaling extensions to allow the
Call-initiator to identify the Call Path explicitly when transit
nodes (besides the Call-initiator and Call-terminator) are involved
in these Calls.
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 [RFC2119].
Table of Contents
1. Introduction.................................................2
2. Motivation...................................................3
3. Solution.....................................................5
4. Operations...................................................8
4.1. User-Initiated Calls....................................8
5. Security Considerations......................................9
6. Manageability Considerations.................................9
7. IANA Considerations..........................................9
7.1. Call_ERO Object.........................................9
7.2. Call_RRO Object........................................10
7.3. RSVP Error Codes and Error Values......................10
8. Normative References........................................10
9. Authors' Addresses..........................................12
Acknowledgment.................................................12
1. Introduction
The concept of a Generalized Multi-Protocol Label Switching (GMPLS)
Call is introduced in [RFC4974]. A Call is an association between
endpoints and possibly between key transit points (such as network
boundaries) in support of an instance of a service. The requirements
of Calls and the RSVT-TE extensions in support of Calls are also
described in [RFC4974].
A Call is usually established between end-points to verify polices
and authorization applied on these end-points. However, in a multi-
domain environment, some key polices and authorization are usually
Zhang Expires September 01, 2009 [Page 2]
Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009
deployed on the corresponding domain border nodes (domain ingress or
egress nodes), so these border nodes are also involved in processing
the Call when the Call is going through these domains. These nodes
that process the Call are known as "Call Managers".
Although it is stated that the mechanisms proposed in [RFC4974] are
applicable to any environment (including multi-area), the "Call Path"
is determined hop-by-hop by each Call Manager in sequence along the
path of the Call. That is, each Call Manager forwards the Notify
message that is used to manage the Call to the next Call Manager
along the Call Path. The Notify messages are targeted at (i.e., carry
the IP address of) the next Call Manager, and the route that the
messages follow through the network to reach the next Call Manager is
not important.
However, it is desirable to allow the Call-initiator to determine the
Call Path and to signal it explicitly in some cases (especially in
the multi-domain case).
This document describes RSVP-TE signaling extensions to allow the
Call-initiator to identify the Call Path explicitly when transit Call
Managers (besides the Call-initiator and Call-terminator) are
involved in a Call.
Note that Call and Connection are separated in the signaling, and
Call procedures do not impact the Connection procedures, so this
document does not modify any Connection procedures defined in
[RFC3471], [RFC3473], [RFC4208], and other existing protocol family.
2. Motivation
In some cases, it is desirable to set up a Call through not only the
Call-initiator and Call-terminator, but also some transit Call
Manager nodes (e.g., transit border domain nodes) to verify the
corresponding polices and authorization applied on these nodes.
For instance, in the multi-domain case as shown in Figure 1, there
are three interconnected domains. Nodes I, D11, and D12 are in Domain
1, and the nodes D11 and D12 are the border nodes. Nodes D21, D22,
D23, and D24 are the border nodes of Domain 2, and the internal nodes
of Domain 2 are not shown in the figure. Nodes D31, D32, and E are in
Domain 3, and the nodes D31 and D32 are the border nodes.
Policies and authorization are often applied in domain border nodes,
such as the nodes D11, D12, D21, D22, D23, D24, D31, and D32 in this
example. Therefore, in this case, when a Call between Call-initiator
(node I) and Call-terminator (node E) is going to be setup, the Call
Zhang Expires September 01, 2009 [Page 3]
Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009
should be processed in some domain border nodes (for example, the
nodes D11, D21, D23, D31 should process the Call when the Call Path
I-D11-D21-D23-D31-E is selected).
Note that in this case, there may be several alternative Call Paths
between Call-initiator and Call-terminator. For example, in the
Figure 1, the possible Call paths may be I-D11-D21-D23-D31-E or I-
D12-D22-D24-D32-E, or some other path depending on the
interconnectivity across the domains.
+------------------+ +----------------+ +-----------------+
| +--+ | | +--+ +--+ | | +--+ |
| --| |--|--|--| |----| |--|--|--| |-- |
| / | | | | | | | | | | | | \ |
| / +--+ | | +--+ +--+ | | +--+ \ |
| +--+ / D11 | | D21 D23 | | D31 \ +--+ |
| | |- | | | | -| | |
| | |- | | | | -| | |
| +--+ \ +--+ | | +--+ +--+ | | +--+ / +--+ |
| I \ | | | | | | | | | | | | / E |
| ---| |--|--|--| |----| |--|--|--| |--- |
| +--+ | | +--+ +--+ | | +--+ |
| D12 | | D22 D24 | | D32 |
| | | | | |
+------------------+ +----------------+ +-----------------+
Domain1 Domain2 Domain3
Figure 1: Multi-domain Scenario
Note that how to determine the Call Path is out of the scope of this
document.
According to the Section 7.3.1 of [RFC 4974], it is already supported
that the third parties (i.e., non-end points such as External Call
Managers) are involved in the Call, but there is no mechanisms for
the Call-initiator to control the Call Path. The Call Path is
determined by each Call Manager in turn selecting the next Call
Manager on the path to the Call-terminator and forwarding the Notify
message that sets up the Call.
However, in the case of a multi-domain Call, commercial and policy
motivations normally play a role in selecting the Call Path. This
selection may be at a coarse level (for example, identifying which
domains should or should not be used), or may be at a finer level
(for example, identifying which Call Managers to use). Note that
there is no concept of specifying links or resources within the Call
Zhang Expires September 01, 2009 [Page 4]
Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009
Path as the Call is an ordered association of Call Managers, and not
a data path in the network.
Therefore, it is desirable to allow full control for the Call-
initiator, which means that the Call-initiator can identify the full
Call Path explicitly. Moreover, the management plane needs to be able
to identify the Call Path explicitly as an instruction to the Call-
initiator.
This document defines protocol extensions that provide a solution for
these requirements.
3. Solution
In order to identify the Call Path explicitly for the Call-initiator,
the CALL_EXPLICIT_ROUTE object (Call_ERO) is introduced.
The format of the Call_ERO is defined as follows:
Class = TBD (0bbbbbbb), 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) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Call_ERO is the same as EXPLICIT_ROUTE object (ERO)
described in [RFC3209]. And the subobjects including IPv4 prefix,
IPv6 prefix, and autonomous system number defined in [RFC3209] could
be reused as subobjects of Call_ERO.
In inter-domain environment, it is possible to collect and
communicate information about the inter-domain links because the
domains usually don't share the Traffic Engineering (TE) information
between domains. So Call_RRO and its Link_Capability subobject are
introduced to record this information.
The format of the Call_RRO is defined as follows:
Class = TBD (11bbbbbb), C_Type = 1
Zhang Expires September 01, 2009 [Page 5]
Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009
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) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Call_RRO is the same as RECORD_ROUTE object (RRO)
described in [RFC3209].
The subobjects of RRO including IPv4 address and IPv6 address defined
in [RFC3209] could be reused as subobjects of Call_RRO and the
formats of the subobjects for LINK_CAPABILITY object [RFC4974]
including type 1, type 2, type 4, type 64 and type 65 could be reused
as Link_Capability subobjects of Call_RRO (Note that the
corresponding types are redefined as type 3, type 4, type 5, type 64
and type 65).
The following subobjects are defined currently:
- Type 1: IPv4 address subobject defined in Section 4.4.1.1 of
[RFC3209].
- Type 2: IPv6 address subobject defined in Section 4.4.1.2 of
[RFC3209].
- Type 3: the link local IPv4 address of a link or a numbered
bundle using the format defined in [RFC3209].
- Type 4: the link local IPv6 address of a link or a numbered
bundle using the format defined in [RFC3209].
- Type 5: the link local identifier of an unnumbered link or
bundle using the format defined in [RFC3477].
- Type 64: the Maximum Reservable Bandwidth corresponding to this
link or bundle (see [RFC4201]).
- Type 65: the interface switching capability descriptor (see
[RFC4202]) corresponding to this link or bundle (see
also [RFC4201]).
Zhang Expires September 01, 2009 [Page 6]
Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009
Similar to the Label RRO [RFC3209], the Link_Capability subobjects
are pushed onto the Call_RRO object prior to pushing on the IPv4 or
IPV6 subobject. A Call Manager MUST NOT push on a Link_Capability
subobject without also pushing on an IPv4 or IPv6 subobject.
Note that multiple Link_Capability subobjects following IPv4 or IPv6
subobject can be presented in the Call_RRO to collect all the
possible link information between domains.
The revised Notify message is as follows using the meta-language
described in [RBNF]:
<Notify message> ::= <Common Header> [ <INTEGRITY> ]
[[ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]...]
[ <MESSAGE_ID> ]
<ERROR_SPEC>
<notify session list>
Where
<notify session list> ::= [ <notify session list> ]
<notify session>
<notify session> ::= <SESSION> [ <ADMIN_STATUS> ]
[ <POLICY_DATA>...]
[ <LINK_CAPABILITY> ]
[ <SESSION_ATTRIBUTE> ]
[ <Call_ERO> ]
[ <Call_RRO> ]
[ <sender descriptor> | <flow descriptor> ]
And where:
<sender descriptor> ::= see [RFC3473]
<flow descriptor> ::= see [RFC3473]
Zhang Expires September 01, 2009 [Page 7]
Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009
4. Operations
The processes for the revised Notify message comply with the
procedures described in [RFC3974] except that the Call_ERO is
processed at the Call Managers. The processes for the Call_ERO and
Call_RRO are similar to the Connection ERO and RRO [RFC3209].
The procedures of Call Setup for the revised Notify message are
summarized as follows (other procedures are the same as [RFC3974]):
(1)The Call-initiator initiates Call setup and processes the Call
locally (e.g., verifies the policy, etc.). After that, it adds
the Call_ERO to the Notify message, including the sub-objects to
identify the Call Path. If Call_RRO is required, it also should
add Call_RRO to the Notify message. Then the Call-initiator sends
the Notify message to the first Call Manager indicated by the
first sub-object of the Call_ERO (Note that there is no Label
_Recording for Call_RRO).
(2)The transit Call Managers process the Call when they receive the
Notify messages. After that, they remove themselves from the
Call_ERO. If Call_RRO is presented in the Notify message, it
should also process Call_RRO similar to [RFC3209]. Then it sends
the Notify message to the next Call Manager identified by the
Call_ERO.
(3)Step 2 recurs until the Notify message gets to the Call-
terminator. And the corresponding Notify message returns to Call-
initiator in the inverse direction.
If, at any time, the Call_ERO is absent or present but empty (for
example, when a transit Call Manager removes itself from the
Call_ERO), a Call Manager MUST select a next Call Manager on the Call
Path toward the Call-terminator (identified in the Session object of
the Notify message). This next Call Manager may be another transit
Call Manager or may be the Call-terminator itself. The Call Manager
MAY create a new Call_ERO if none exists to define hops to the Call-
terminator, or may add hops to the existing Call_ERO between itself
and the next hop in the received Call_ERO. Such actions are subject
to local policy.
4.1. User-Initiated Calls
The extensions in this document can also be applied in user-initiated
calls, although the example described in this document is about
network-initiated Call. Note that, in this case, the first node
within the first network domain may be responsible for specifying the
Zhang Expires September 01, 2009 [Page 8]
Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009
Call Path explicitly in the Notify message. The procedures should
comply with the description in the Section 7.2 of [RFC 4974].
5. Security Considerations
The security considerations about Call setup in single domain are
described in [RFC 4974]. In the case of multi-domain environment, the
security about Call is similar to that of Connection which is
described in [RFC 5151]. Therefore, please refer to the corresponding
Security Consideration sections in [RFC 4974] and [RFC 5151] to take
into account the security issues.
6. Manageability Considerations
The mechanisms defined in this document call upon the use of policy
at Call Managers. Such policy SHOULD be available for configuration
by the operator either directly acting on the Call Manager or through
a policy server. Important information for the application of policy
is carried in the Call establishment messages (Notify messages) in
the Session, Session_Attributes, Sender_Template, Link_Capability,
and Policy_Data objects.
The mechanism used to determine the entire Call Path or next Call
Manager in a Call Path is beyond the scope of this document. One
solution is to allow configuration of the Call Path from the operator
as part of the service request (just as the explicit path of a label
switched path (LSP) can be specified by the operator).
Operators will expect to be able to inspect Call Managers and
determine for which Calls they are initiator, transit, or terminator.
Furthermore, they will expect to be able to inspect a Call at any
Call Manager that it uses, and determine all information about the
Call including its Call Path.
7. IANA Considerations
This document introduces two new classes named Call_ERO and Call_RRO.
7.1. Call_ERO Object
Class-Num = TBD (0bbbbbbb)
C-Type=1 (Call_ERO)
The Call_ERO object is only used for Call messages in Notify messages.
Subobjects of the Call_ERO object with C-Type 1:
Zhang Expires September 01, 2009 [Page 9]
Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009
1 IPv4 prefix
2 IPv6 prefix
32 Autonomous system number
7.2. Call_RRO Object
Class-Num = TBD (11bbbbbb)
C-Type=1 (Call_RRO)
The Call_RRO object is only used for Call messages in Notify messages.
The subobjects of Call_RRO are defined in Section 3 of this document.
7.3. RSVP Error Codes and Error Values
The Call message (Notify message) should be rejected when any Call
Manager which receives the Call message including Call_ERO does not
recognize the Call_ERO.
o Error Codes:
- Call Management (value 32)
o Error Values:
- Call Management/Unknown Call_ERO (value=TBD)
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4974] D. Papadimitriou, A. Farrel, "Generalized MPLS (GMPLS)
RSVP-TE Signaling Extensions in Support of Calls ", RFC
4974, August 2007.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions
to RSVP for LSP Tunnels", RFC 3209, December 2001.
Zhang Expires September 01, 2009 [Page 10]
Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
January 2003.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, October 2005.
[RFC5151] A. Farrel, A. Ayyangar, JP. Vasseur, "Inter-Domain MPLS and
GMPLS Traffic Engineering-Resource Reservation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 5151,
February 2008.
[RBNF] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used
in Various Protocol Specifications", draft-farrel-rtg-
common-bnf, work in progress.
Zhang Expires September 01, 2009 [Page 11]
Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009
9. Authors' Addresses
Fatai Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972912
Email: zhangfatai@huawei.com
Dan Li
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base,
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28973237
Email: danli@huawei.com
Jianhua Gao
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972912
Email: gjhhit@huawei.com
Acknowledgment
TBD.
Intellectual Property
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Zhang Expires September 01, 2009 [Page 12]
Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009
Copies of Intellectual Property disclosures made to the IETF
Secretariat 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 on-line IPR
repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Disclaimer of Validity
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Full Copyright Statement
Zhang Expires September 01, 2009 [Page 13]
Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Zhang Expires September 01, 2009 [Page 14]