One document matched: draft-zhang-ccamp-gmpls-call-extensions-01.txt
Differences from draft-zhang-ccamp-gmpls-call-extensions-00.txt
Network work group Fatai Zhang
Internet Draft Dan Li
Intended status: Standards Track Jianhua Gao
Expires: January 2010 Huawei
July 08, 2009
RSVP-TE extensions to GMPLS Calls
draft-zhang-ccamp-gmpls-call-extensions-01.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 January 08, 2010.
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 January 2010 [Page 1]
Internet-Draft RSVP-TE extensions to GMPLS Calls July 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...................................................6
4.1. User-Initiated Calls....................................7
5. Security Considerations......................................7
6. Manageability Considerations.................................7
7. IANA Considerations..........................................8
7.1. ERO Object..............................................8
7.2. RRO Object..............................................8
7.3. RSVP Error Codes and Error Values.......................8
8. Normative References.........................................9
9. Authors' Addresses..........................................10
Acknowledgment.................................................10
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 January 2010 [Page 2]
Internet-Draft RSVP-TE extensions to GMPLS Calls July 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 January 2010 [Page 3]
Internet-Draft RSVP-TE extensions to GMPLS Calls July 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 January 2010 [Page 4]
Internet-Draft RSVP-TE extensions to GMPLS Calls July 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 explicit Call Path can be specified by the EXPLICIT_ROUTE object
(ERO) [RFC3209].
A new C_Type of ERO is suggested, C_Type = 2 (suggested, TBD by
IANA)), Call Explicit Route.
It is obvious that the Call Path can also be recorded by the
RECORD_ROUTE object (RRO) [RFC3209].
A new C_Type of RRO is suggested, C_Type = 2 (suggested, TBD by IANA),
Call Record Route.
Note that the procedures of ERO and RRO for Call Path are similar as
defined in [RFC3209].
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> ]
Zhang Expires January 2010 [Page 5]
Internet-Draft RSVP-TE extensions to GMPLS Calls July 2009
<notify session>
<notify session> ::= <SESSION> [ <ADMIN_STATUS> ]
[ <POLICY_DATA>...]
[ <LINK_CAPABILITY> ]
[ <SESSION_ATTRIBUTE> ]
[ <ERO> ]
[ <RRO> ]
[ <sender descriptor> | <flow descriptor> ]
And where:
<sender descriptor> ::= see [RFC3473]
<flow descriptor> ::= see [RFC3473]
4. Operations
The processes for the revised Notify message comply with the
procedures described in [RFC3974] except that the ERO and RRO are
processed at the Call Managers. The processes for the ERO and 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 ERO to the Notify message, including the sub-objects to
identify the Call Path. If RRO is required, it also should add
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 ERO (Note that there is no Label Recording in
this case).
(2)The transit Call Managers process the Call when they receive the
Notify messages. After that, they remove themselves from the ERO.
If RRO is presented in the Notify message, it should also process
RRO similar to [RFC3209]. Then it sends the Notify message to the
next Call Manager identified by the ERO.
Zhang Expires January 2010 [Page 6]
Internet-Draft RSVP-TE extensions to GMPLS Calls July 2009
(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 (Note that the inverse Notify
message may include RRO object if needed, but it should not
include ERO object).
If, at any time, the ERO is absent or present but empty (for example,
when a transit Call Manager removes itself from the 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 ERO if none exists to define hops to the Call-terminator, or may
add hops to the existing ERO between itself and the next hop in the
received 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
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
Zhang Expires January 2010 [Page 7]
Internet-Draft RSVP-TE extensions to GMPLS Calls July 2009
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 a new C_Type ERO and RRO.
7.1. ERO Object
Class-Num = 20
C-Type=2 (suggested, TBD by IANA), Call Explicit Route
This type indicates that this ERO is used for Call messages in Notify
messages.
7.2. RRO Object
Class-Num = 21
C-Type=2 (suggested, TBD by IANA), Call Record Route
This type indicates that this RRO is used for Call messages in Notify
messages.
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 ERO does not
recognize the ERO.
o Error Codes:
- Call Management (value 32)
o Error Values:
- Call Management/Unknown ERO (value=TBD)
Zhang Expires January 2010 [Page 8]
Internet-Draft RSVP-TE extensions to GMPLS Calls July 2009
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.
[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 January 2010 [Page 9]
Internet-Draft RSVP-TE extensions to GMPLS Calls July 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 January 2010 [Page 10]
Internet-Draft RSVP-TE extensions to GMPLS Calls July 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 January 2010 [Page 11]
Internet-Draft RSVP-TE extensions to GMPLS Calls July 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 January 2010 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 12:18:17 |