Skip to main content

PCEP Extensions for Establishing Relationships Between Sets of LSPs and Virtual Networks
draft-leedhody-pce-vn-association-03

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Young Lee , Dhruv Dhody , Xian Zhang , Daniele Ceccarelli
Last updated 2017-09-18 (Latest revision 2017-03-13)
Replaced by draft-ietf-pce-vn-association, draft-ietf-pce-vn-association, draft-ietf-pce-vn-association, RFC 9358
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-leedhody-pce-vn-association-03
PCE Working Group                                                 Y. Lee
Internet-Draft                                                  D. Dhody
Intended Status: Standards track                                X. Zhang
Expires:  March 22, 2017                             Huawei Technologies
                                                           D. Ceccarelli
                                                                Ericsson
                                                      September 18, 2017

  PCEP Extensions for Establishing Relationships Between Sets of LSPs 
                       and Virtual Networks
                 draft-leedhody-pce-vn-association-03

Abstract

   This document describes how to extend Path Computation Element (PCE)
   Communication Protocol (PCEP) association mechanism introduced by the
   PCEP Association Group specification, to further associate sets of
   LSPs with a higher-level structure such as a virtual network (VN)
   requested by clients or applications. This extended association
   mechanism can be used to facilitate virtual network control using PCE
   architecture.

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."

 

Lee & Dhody, et al.      Expires March 22, 2017                 [Page 1]
Internet-Draft            PCEP VN Association            September, 2017

   The list of current Internet-Drafts can be accessed at
   https://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   https://www.ietf.org/shadow.html

   This Internet-Draft will expire on March 22, 2017.

Copyright Notice

   Copyright (c) 2017 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction...................................................2
      1.1. Requirements Language.....................................3
   2. Terminology....................................................4
   3. Operation Overview.............................................4
   4. Extensions to PCEP.............................................4
   5. Applicability to H-PCE architecture............................6
   6. Security Considerations........................................7
   7. IANA Considerations............................................7
      7.1. Association Object Type Indicator.........................7
      7.2. PCEP TLV Type Indicator...................................8
      7.3. PCEP Error................................................8
   8. References.....................................................8
      8.1. Normative References......................................8
      8.2. Informative References....................................9
   Author's Addresses................................................9

1. Introduction

   The Path Computation Element communication Protocol (PCEP) provides
   mechanisms for Path Computation Elements (PCEs) to perform path
   computations in response to Path Computation Clients' (PCCs)
   requests.
 

Lee & Dhody, et al.      Expires March 22, 2017                 [Page 2]
Internet-Draft            PCEP VN Association            September, 2017

   [RFC8051] describes general considerations for a stateful PCE
   deployment and examines its applicability and benefits, as well as
   its challenges and limitations through a number of use cases.
   [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to
   provide stateful control. A stateful PCE has access to not only the
   information carried by the network's Interior Gateway Protocol (IGP),
   but also the set of active paths and their reserved resources for its
   computations.  The additional state allows the PCE to compute
   constrained paths while considering individual LSPs and their
   interactions.

   [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and
   teardown of PCE-initiated LSPs under the stateful PCE model. 

   [I-D.ietf-pce-association-group] introduces a generic mechanism to
   create a grouping of LSPs. This grouping can then be used to define
   association between sets of LSPs or between a set of LSPs and a set
   of attributes.

   [ACTN-REQ] describes various Virtual Network (VN) operations
   initiated by a customer/application. In this context, there is a need
   for associating a set of LSPs with a VN "construct" to facilitate VN
   operations in PCE architecture. This association allows the PCEs to
   identify which LSPs belong to a certain VN. The PCE could then use
   this association to optimize all LSPs belonging to the VN together.
   The PCE could further take VN specific actions on the LSPs such as
   relaxation of constraints, policy actions, setting default behavior
   etc.

   [I-D.ietf-pce-applicability-actn] examines the PCE and ACTN
   architecture and describes how the PCE architecture is applicable to
   ACTN. [RFC6805] and [I-D.ietf-pce-stateful-hpce] describes a
   hierarchy of stateful PCEs with Parent PCE coordinating multi-domain
   path computation function between Child PCE(s) and thus making it the
   base for PCE applicability for ACTN. In this text child PCE would be
   same as Physical Network Controller (PNC), and the parent PCE as
   Multi-domain Service Coordinator (MDSC) [ACTN-FWK]. 

   This document specifies a PCEP extension to associate a set of LSPs
   based on Virtual Network (VN) (or customer). A Virtual Network (VN)
   is a customer view of the TE network.  Depending on the agreement
   between client and provider various VN operations and VN views are
   possible as described in [ACTN-FWK].

1.1. Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
 

Lee & Dhody, et al.      Expires March 22, 2017                 [Page 3]
Internet-Draft            PCEP VN Association            September, 2017

   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

 

Lee & Dhody, et al.      Expires March 22, 2017                 [Page 4]
Internet-Draft            PCEP VN Association            September, 2017

2. Terminology

   The terminology is as per [RFC4655], [RFC5440], [RFC6805], [I-D.ietf-
   pce-stateful-pce] and [ACTN-FWK]..

3. Operation Overview

   As per [I-D.ietf-pce-association-group], LSPs are associated with
   other LSPs with which they interact by adding them to a common
   association group. 

   An association group based on VN is useful for various optimizations
   that should be applied by considering all the LSPs in the
   association. This includes, but not limited to - 

      o Path Computation: When computing path for a LSP, the impact of
      this LSP, on the other LSPs belonging to the same VN is useful to
      analyze. The aim would be optimize overall VN and all LSPs, rather
      than a single LSP. Also, the optimization criteria such as
      minimize the load of the most loaded link (MLL) [RFC5541] and
      other could be applied for all the LSP belonging to the same VN,
      identified by the VN association. 

      o Path Re-Optimization: The child PCE or the parent PCE would like
      to use advanced path computation algorithm and optimization
      technique that consider all the LSPs belonging to a VN/customer
      and optimize them all together during the re-optimization. 

      This association is useful in PCEP session between parent PCE
      (MDSC) and child PCE (PNC). 

 

Lee & Dhody, et al.      Expires March 22, 2017                 [Page 5]
Internet-Draft            PCEP VN Association            September, 2017

                                   ******
                         ..........*MDSC*..............................
                      .            ****** ..                   MPI    .
                   .                .        .                 PCEP   .
                .                   .          .   PCInitiate LSPx   .
              .                    .             .   with VNAG = 10   .
             .                    .                .                  .
            .                    .                  .                 .
           .                    .                    .                .
           v                    v                    v                .
         ******               ******               ******             .
         *PNC1*               *PNC2*               *PNC4*             .
         ******               ******               ******             .
         +---------------+    +---------------+    +---------------+  .
         |A              |----|               |----|              C|  .
         |               |    |               |    |               |  .
         |DOMAIN 1       |----|DOMAIN 2       |----|DOMAIN 4       |  .
         +------------B13+    +---------------+    +B43------------+  .
                                                  /                  .
                             ******              /                   .
                             *PNC3*<............/.....................
                             ******            /
                             +---------------+/
                              B31           B34
                              |               |
                              |DOMAIN 3      B|
                              +---------------+

         MDSC -> Parent PCE
         PNC  -> Child  PCE
         MPI  -> PCEP

   In this draft, this grouping is used to define associations between a
   set of LSPs and a virtual network.

   One new optional Association Object-type is defined based on the
   generic Association object -

      o  VN Association Group (VNAG)

   Thus this document define one new association type called "VN
   Association Type" of value TBD1.  The scope and handling of VNAG
   identifier is similar to the generic association identifier defined
   in [I-D.ietf-pce-association-group].

   Local polices on the PCE MAY define the computational and
   optimization behavior for the LSPs in the VN. An LSP MUST belong to a
   single VNAG. If an implementation encounters more than one VNAG, it
 

Lee & Dhody, et al.      Expires March 22, 2017                 [Page 6]
Internet-Draft            PCEP VN Association            September, 2017

   MUST consider the first occurrence and ignore the others. 

   This Association-Type is dynamic in nature and created by the Parent
   PCE (MDSC) for the LSPs belonging to the same VN or customer. These
   associations are conveyed via PCEP messages to the PCEP peer.
   Operator-configured Association Range SHOULD NOT be set for this
   association-type and MUST be ignored.

4. Extensions to PCEP

    [I-D.ietf-pce-association-group] introduces the ASSOCIATION object,
   the format of VNAG is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Reserved                      | Flags                       |R|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Association type=TBD1  |          Association ID       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     IPv4 Association Source                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                         Optional TLVs                       //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Reserved              |            Flags            |R|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Association type=TBD1    |      Association ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                    IPv6 Association Source                    |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                   Optional TLVs                             //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1: The VNAG Object formats

   Please refer to [I-D.ietf-pce-association-group] for the definition
   of each field in Figure 1. This document defines one mandatory TLV
   "VIRTUAL-NETWORK-TLV" and one optional TLV "VENDOR-INFORMATION-TLV" -
   

      o VIRTUAL-NETWORK-TLV: Used to communicate the VN Identifier.
 

Lee & Dhody, et al.      Expires March 22, 2017                 [Page 7]
Internet-Draft            PCEP VN Association            September, 2017

      o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor 
      specific behavioral information, described in [RFC7470].

   The format of VIRTUAL-NETWORK-TLV is as follows.
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type=TBD2           |       Length (variable)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                   Virtual Network Name                      //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 2: The VIRTUAL-NETWORK-TLV formats

   Type: TBD2 (to be allocated by IANA)

   Length: Variable Length

   Virtual Network Name(variable): an unique symbolic name for the VN. 
   The VN name is a human-readable string that identifies a VN. 
   The VN name MUST remain constant throughout an LSP's lifetime, 
   which may span across multiple consecutive PCEP sessions and/or 
   PCC restarts.  The VN name MAY be specified by an operator or 
   auto-generated by the PCEP speaker.

   The VIRTUAL-NETWORK-TLV MUST be included in VNAG object.If a PCEP
   speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it
   MUST send a PCErr message with Error-Type=6 (mandatory object
   missing) and Error-Value=TBD3 (VIRTUAL-NETWORK-TLV missing) and close
   the session.

   The format of VENDOR-INFORMATION-TLV is defined in [RFC7470].

5. Applicability to H-PCE architecture

   The ability to compute shortest constrained TE LSPs in Multiprotocol
   Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across
   multiple domains has been identified as a key motivation for PCE
   development.  [RFC6805] describes a Hierarchical PCE (H-PCE)
   architecture which can be used for computing end-to-end paths for
   inter-domain MPLS Traffic Engineering (TE) and GMPLS Label Switched
   Paths (LSPs).  Within the hierarchical PCE architecture, the parent
   PCE is used to compute a multi-domain path based on the domain
   connectivity information.  A child PCE may be responsible for a
   single domain or multiple domains, it is used to compute the intra-
 

Lee & Dhody, et al.      Expires March 22, 2017                 [Page 8]
Internet-Draft            PCEP VN Association            September, 2017

   domain path based on its domain topology information.

   [I-D.ietf-pce-stateful-hpce] introduces general considerations for
   stateful PCE(s) in hierarchical PCE architecture.  In particular, the
   behavior changes and additions to the existing stateful PCE
   mechanisms in the context of a H-PCE architecture.

   In Stateful H-PCE architecture, the Parent PCE receives a virtual
   network creation request by its client over its Northbound API. This
   VN is uniquely identified by an Association ID in VNAG as well as the
   VIRTUAL-NETWORK name. This VN may comprise multiple LSPs in the
   network in a single domain or across multiple domains.

   As the Parent PCE computes the optimum E2E paths for each tunnel in
   VN, it MUST associate each LSP with the VN to which it belongs.
   Parent PCE sends a PCInitiate Message with this association
   information in the VNAG Object (See Section 4 for details). This in
   effect binds an LSP that is to be instantiated at the child PCE with
   the VN.

   Whenever changes occur with the instantiated LSP in a domain network,
   the domain child PCE reports the changes using a PCRpt Message in
   which the VNAG Object indicates the relationship between the LSP and
   the VN.

   Whenever an update occurs with VNs in the Parent PCE (via the
   client's request), the parent PCE sends an PCUpd Message to inform
   each affected child PCE of this change.

   The Child PCE could then use this association to optimize all LSPs
   belonging to the same VN association together. The Child PCE could
   further take VN specific actions on the LSPs such as relaxation of
   constraints, policy actions, setting default behavior etc. The parent
   PCE could also maintain all E2E LSP or per-domain path segments under
   a single VN association. 

6. Security Considerations

   This document defines one new type for association, which do not add
   any new security concerns beyond those discussed in [RFC5440], [I-
   D.ietf-pce-stateful-pce] and [I-D.ietf-pce-association-group] in
   itself.

   Some deployments may find VN associations and their implications as
   extra sensitive and thus should employ suitable PCEP security
   mechanisms like TCP-AO or [I-D.ietf-pce-pceps].

7. IANA Considerations
 

Lee & Dhody, et al.      Expires March 22, 2017                 [Page 9]
Internet-Draft            PCEP VN Association            September, 2017

7.1. Association Object Type Indicator

   This document defines a new association type, originally defined in
   [I-D.ietf-pce-association-group], for path protection.  IANA is
   requested to make the assignment of a new value for the sub-registry
   "ASSOCIATION Type Field" (request to be created in [I-D.ietf-pce-
   association-group]), as follows:

      Value     Name                        Reference

      TBD1      VN Association Type         [This I.D.]

7.2. PCEP TLV Type Indicator

   This document defines a new TLV for carrying additional information
   of LSPs within a path protection association group.  IANA is
   requested to make the assignment of a new value for the existing
   "PCEP TLV Type Indicators" registry as follows:

      Value     Name                        Reference

      TBD2      VIRTUAL-NETWORK-TLV         [This I.D.]

7.3. PCEP Error

   This document defines new Error-Type and Error-Value related to path
   protection association.  IANA is requested to allocate new error
   values within the "PCEP-ERROR Object Error Types and Values" sub-
   registry of the PCEP Numbers registry, as follows:

      Error-Type  Meaning

      6           Mandatory Object missing
                  Error-value=TBD3: VIRTUAL-NETWORK TLV missing [This
   I.D.]

8.  Manageability Considerations

8.1.  Control of Function and Policy

   An operator MUST BE allowed to mark LSPs that belong to the same VN.
   This could also be done automatically based on the VN configuration.

8.2.  Information and Data Models

   The PCEP YANG module [I-D.ietf-pce-pcep-yang] should support the
   association between LSPs including VN association.
 

Lee & Dhody, et al.      Expires March 22, 2017                [Page 10]
Internet-Draft            PCEP VN Association            September, 2017

8.3.  Liveness Detection and Monitoring

   Mechanisms defined in this document do not imply any new liveness
   detection and monitoring requirements in addition to those already
   listed in [RFC5440].

8.4.  Verify Correct Operations

   Mechanisms defined in this document do not imply any new operation
   verification requirements in addition to those already listed in
   [RFC5440].

8.5.  Requirements On Other Protocols

   Mechanisms defined in this document do not imply any new requirements
   on other protocols.

8.6.  Impact On Network Operations

   Mechanisms defined in this document do not have any impact on network
   operations in addition to those already listed in [RFC5440].

9. References

9.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, DOI
             10.17487/RFC2119, March 1997.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
             Element (PCE) Communication Protocol (PCEP)", RFC 5440,
             March 2009.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
             2119 Key Words", BCP 14, RFC 8174, May 2017.

   [I-D.ietf-pce-stateful-pce] E. Crabbe, I. Minei, J. Medved, and R.
             Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce-
             stateful-pce, work in progress.

   [I-D.ietf-pce-pce-initiated-lsp] E. Crabbe, et. al., "PCEP Extensions
             for PCE-initiated LSP Setup in a Stateful PCE Model",
             draft-ietf-pce-pce-initiated-lsp, work in progress.

   [I-D.ietf-pce-association-group] I, Minei, Ed., "PCEP Extensions for
             Establishing Relationships Between Sets of LSPs", draft-
             ietf-pce-association-group, work in progress.
 

Lee & Dhody, et al.      Expires March 22, 2017                [Page 11]
Internet-Draft            PCEP VN Association            September, 2017

9.2. Informative References

   [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation
             Element (PCE)-Based Architecture", RFC 4655, August 2006.

   [RFC6805] A. Farrel and D. King, "The Application of the Path
             Computation Element Architecture to the Determination of a
             Sequence of Domains in MPLS and GMPLS", RFC 6805, November
             2012.

   [I-D.ietf-pce-applicability-actn] Dhody D., Lee Y., and D.
             Ceccarelli, "Applicability of Path Computation Element
             (PCE) for Abstraction and Control of TE Networks (ACTN)",
             draft-ietf-pce-applicability-actn, work-in-progress.

   [I-D.ietf-pce-stateful-hpce] Dhody, D. and Lee, Y., "Hierarchical
             Stateful Path Computation Element (PCE)",
             draft-ietf-pce-stateful-hpce, work in progress.

   [ACTN-REQ] Y. Lee, D. Dhody, S. Belotti, K. Pithewan, and D.
             Ceccarelli, "Requirements for Abstraction and Control of TE
             Networks", draft-ietf-teas-actn-requirements, work in
             progress.

   [ACTN-FWK] Ceccarelli D. and Y. Lee, "Framework for Abstraction and
              Control of Transport Networks", draft-ietf-teas-
              actn-framework (work in progress).

   [RFC5541]  Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
              Objective Functions in the Path Computation Element
              Communication Protocol (PCEP)", RFC 5541,
              DOI 10.17487/RFC5541, June 2009,
              <http://www.rfc-editor.org/info/rfc5541>.

   [RFC7470]  Zhang, F. and A. Farrel, "Conveying Vendor-Specific
              Constraints in the Path Computation Element Communication
              Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015,
              <http://www.rfc-editor.org/info/rfc7470>.

   [RFC8051]  Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
              Stateful Path Computation Element (PCE)", RFC 8051,
              DOI 10.17487/RFC8051, January 2017,
              <http://www.rfc-editor.org/info/rfc8051>.

   [I-D.ietf-pce-pceps]
              Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure
              Transport for PCEP", draft-ietf-pce-pceps (work in
              progress).
 

Lee & Dhody, et al.      Expires March 22, 2017                [Page 12]
Internet-Draft            PCEP VN Association            September, 2017

   [I-D.ietf-pce-pcep-yang]
              Dhody, D., Hardwick, J., Beeram, V., and j.
              jefftant@gmail.com, "A YANG Data Model for Path
              Computation Element Communications Protocol (PCEP)",
              draft-ietf-pce-pcep-yang (work in progress).

 

Lee & Dhody, et al.      Expires March 22, 2017                [Page 13]
Internet-Draft            PCEP VN Association            September, 2017

 Author's Addresses

   Young Lee (Editor)
   Huawei Technologies
   5340 Legacy Drive, Building 3
   Plano, TX 75023, 
   USA

   Email: leeyoung@huawei.com

   Dhruv Dhody (Editor)
   Huawei Technologies
   Divyashree Technopark, Whitefield
   Bangalore, Karnataka  560066
   India

   Email: dhruv.ietf@gmail.com

   Xian Zhang
   Huawei Technologies
   China

   Email: zhang.xian@huawei.com

   Daniele Ceccarelli
   Ericsson
   Torshamnsgatan,48
   Stockholm, 
   Sweden

   Email: daniele.ceccarelli@ericsson.com

Lee & Dhody, et al.      Expires March 22, 2017                [Page 14]