[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/