PCE Working Group                                               D. Dhody
Internet-Draft                                                     Q. Wu
Intended status: Standards Track                     Huawei Technologies
Expires: October 21, 2016                                 April 19, 2016


     Path Computation Element communication Protocol extension for
          relationship between LSPs and Attributes or Policies
                  draft-dhody-pce-association-attr-04

Abstract

   The Path Computation Element (PCE) provides functions of path
   computation in support of traffic engineering in networks controlled
   by Multi-Protocol Label Switching (MPLS) and Generalized MPLS
   (GMPLS).

   This document defines a mechanism to create associations between a
   set of LSPs and a set of attributes (such as configuration
   parameters) or policies.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on October 21, 2016.

Copyright Notice

   Copyright (c) 2016 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



Dhody & Wu              Expires October 21, 2016                [Page 1]


Internet-Draft              ASSOC-ATTR-POLICY                 April 2016


   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 . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Opaque Identifier . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Policy based Constraints  . . . . . . . . . . . . . . . .   4
     3.3.  Bundled requests  . . . . . . . . . . . . . . . . . . . .   4
   4.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Attribute Association Group . . . . . . . . . . . . . . . . .   6
     5.1.  ATTRIBUTE-OBJECT-TLV  . . . . . . . . . . . . . . . . . .   7
   6.  Policy Association Group  . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Association object Type Indicators  . . . . . . . . . . .   9
     8.2.  PCEP TLV Type Indicators  . . . . . . . . . . . . . . . .   9
   9.  Manageability Considerations  . . . . . . . . . . . . . . . .   9
     9.1.  Control of Function and Policy  . . . . . . . . . . . . .   9
     9.2.  Information and Data Models . . . . . . . . . . . . . . .   9
     9.3.  Liveness Detection and Monitoring . . . . . . . . . . . .   9
     9.4.  Verify Correct Operations . . . . . . . . . . . . . . . .   9
     9.5.  Requirements On Other Protocols . . . . . . . . . . . . .  10
     9.6.  Impact On Network Operations  . . . . . . . . . . . . . .  10
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  10
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     11.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Appendix A.  Contributor Addresses  . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   [RFC5440] describes the Path Computation Element communication
   Protocol (PCEP) which enables the communication between a Path
   Computation Client (PCC) and a Path Control Element (PCE), or between
   two PCEs based on the PCE architecture [RFC4655].

   [I-D.ietf-pce-association-group] introduces a generic mechanism to
   create a grouping of LSPs which can then be used to define
   associations between a set of LSPs and a set of attributes (such as
   configuration parameters or behaviours) and is equally applicable to
   the active and passive modes of a stateful PCE and a stateless PCE.



Dhody & Wu              Expires October 21, 2016                [Page 2]


Internet-Draft              ASSOC-ATTR-POLICY                 April 2016


   This document specifies a PCEP extension to associate one or more
   LSPs with a set of attributes or policies.

   PCEP Extensions for Stateful PCE Model [I-D.ietf-pce-stateful-pce]
   describes a set of extensions to PCEP to enable active control of
   MPLS-TE and GMPLS tunnels.  [I-D.ietf-pce-pce-initiated-lsp]
   describes the setup and teardown of PCE-initiated LSPs under the
   active stateful PCE model, without the need for local configuration
   on the PCC, thus allowing for a dynamic network.  The mechanims
   described in this document is equally applicable to these deployment
   models.

1.1.  Requirements Language

   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 [RFC2119].

2.  Terminology

   The following terminology is used in this document.

   AAG:  Attribute Association Group.

   LSR:  Label Switch Router.

   MPLS:  Multiprotocol Label Switching.

   PAG:  Policy Association Group.

   PCC:  Path Computation Client.  Any client application requesting a
      path computation to be performed by a Path Computation Element.

   PCE:  Path Computation Element.  An entity (component, application,
      or network node) that is capable of computing a network path or
      route based on a network graph and applying computational
      constraints.

   PCEP:  Path Computation Element Communication Protocol.

3.  Motivation

   This section discusses in more detail the motivation and use cases
   for such an association including but not limited to -







Dhody & Wu              Expires October 21, 2016                [Page 3]


Internet-Draft              ASSOC-ATTR-POLICY                 April 2016


3.1.  Opaque Identifier

   An opaque identifier may represent attributes such as configured
   parameters or constraints that a PCEP speaker may invoke on a peer.
   Thus a PCEP speaker may only need an opaque identifier to invoke
   these attributes (parameters or constraints) rather than encoding
   them explicitly in each PCEP message.

   This can also be used for tagging bunch of LSP to a particular
   customer or for creation of virtual network like in case of
   Abstraction and Control of TE Networks (ACTN)
   [I-D.ietf-teas-actn-requirements].  (See
   [I-D.leedhody-pce-vn-association])

3.2.  Policy based Constraints

   In the context of policy-enabled path computation [RFC5394], path
   computation policies may be applied at both a PCC and a PCE.
   Consider an Label Switch Router (LSR) with a policy enabled PCC, it
   receives a service request via signaling, including over a Network-
   Network Interface (NNI) or User Network Interface (UNI) reference
   point, or receives a configuration request over a management
   interface to establish a service.  The PCC may also apply user- or
   service-specific policies to decide how the path selection process
   should be constrained, that is, which constraints, diversities,
   optimization criterion, and constraint relaxation strategies should
   be applied in order for the service LSP(s) to have a likelihood to be
   successfully established and provide necessary QoS and resilience
   against network failures.  The user- or service-specific policies
   applied to PCC and are then passed to the PCE along with the Path
   computation request, in the form of constraints [RFC5394].

   PCEP speaker can use the generic mechanism as per
   [I-D.ietf-pce-association-group] to associate a set of LSPs with
   policy and its resulting path computation constraints.  This
   simplified the path computation message exchanges.

3.3.  Bundled requests

   In some scenarios(e.g.,the topology example described in Section 4.6
   of [RFC6805]), there is a need to send multiple requests with the
   same constraints and attributes to the PCE.  Currently these requests
   are either sent in a separate path computation request (PCReq)
   messages or bundled together in one (or more) PCReq messages.  In
   either case, the constraints and attributes need to be encoded
   separately for each request even though they are exactly identical.





Dhody & Wu              Expires October 21, 2016                [Page 4]


Internet-Draft              ASSOC-ATTR-POLICY                 April 2016


   If a association is used to identify these constraints and attributes
   shared by multiple requests and grouped together via association
   mechanism, thus simplifying the path computation message exchanges.

4.  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.  This grouping can then be used to define
   associations between sets of LSPs or between a set of LSPs and a set
   of attributes (such as configuration parameters).  Similarly grouping
   can also be used to define association between LSPs and policies.
   Two new optional Association Object-types are defined based on the
   generic Association object -

   o  Attribute Association Group (AAG)

   o  Policy Association Group (PAG)

   Thus this document defines two new association type called "Attribute
   Association Type" of value TBD1 and "Policy Association Type" of
   value TBD2.  An AAG can have one or more LSPs and its associated
   attributes and a PAG can have one or more LSPs and its associated
   policy(s).  The scope and handling of AAG and PAG identifier is
   similar to the generic association identifier defined in
   [I-D.ietf-pce-association-group].

   One or more LSP are grouped via a single group identifier as defined
   in [I-D.ietf-pce-association-group].  The attributes that may be
   associated with this set of LSPs may either are -

   o  known to the PCEP peers via some external means like
      configuration, policy enforcement etc (can be considered as 'out-
      of-band').  PCEP speaker simply use the AAG identifier in the PCEP
      message and the peer is supposed to be aware of the associated
      attributes.  This is suitable for stateless PCE where the PCEP
      peers should be aware of the association and its significance
      outside of the protocol.

   o  or communicated to the PCEP peer via PCEP itself on first use (can
      be considered as 'in-band').  PCEP speaker creates a new AAG by
      using a new identifier and the associated attributes are
      communicated via TLVs in association object.  This is applicable
      for stateful PCE only.

   Error handling would be taken up in future revision.





Dhody & Wu              Expires October 21, 2016                [Page 5]


Internet-Draft              ASSOC-ATTR-POLICY                 April 2016


   In case of Policy, PCEP speaker muct be aware of the policy outside
   of PCEP.

5.  Attribute Association Group

   The format of the generic Association object used for AAG is shown in
   Figure 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         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 AAG Object formats

   Type = TBD1 for the Attribute Association Type.

   AAG may carry optional TLVs including but not limited to -

   o  ATTRIBUTE-OBJECT-TLV: Used to communicate associated attributes in
      form of PCEP objects, described in this document.

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




Dhody & Wu              Expires October 21, 2016                [Page 6]


Internet-Draft              ASSOC-ATTR-POLICY                 April 2016


5.1.  ATTRIBUTE-OBJECT-TLV

   The ATTRIBUTE-OBJECT-TLV(s) maybe included in AAG object to associate
   attributes encoded in PCEP objects.

   The format of the ATTRIBUTE-OBJECT-TLV is shown in the following
   figure:

    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=[TBD3]         |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Object-Class  |   OT  |Res|P|I|   Object Length (bytes)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        (Object body)                        //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 2: ATTRIBUTE-OBJECT-TLV format

   The type of the TLV is TBD3 and it has a variable length.  The value
   part consist of a PCEP object (including common header [RFC5440]
   identifying the object) that is associated with this AAG.  This TLV
   identifies the attributes associated with this group.  For each
   attribute a separate TLV is used.  Future PCEP message exchanges may
   only carry the AAG.

6.  Policy Association Group

   The format of the generic Association object used for PAG is shown in
   Figure 3:


















Dhody & Wu              Expires October 21, 2016                [Page 7]


Internet-Draft              ASSOC-ATTR-POLICY                 April 2016


     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 (TBD2)  |      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 (TBD2)  |      Association ID           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                    IPv6 Association Source                    |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    //                   Optional TLVs                             //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                     Figure 3: The PAG Object formats

   Type = TBD2 for the Policy Association Type.

   PAG may carry optional TLVs including but not limited to -

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

7.  Security Considerations

   This document defines two new types for association and a new
   ATTRIBUTE-OBJECT-TLV 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 these associations and their implications
   as extra sensitive and thus should employ suitable PCEP security
   mechanisms like TCP-AO or [I-D.ietf-pce-pceps].




Dhody & Wu              Expires October 21, 2016                [Page 8]


Internet-Draft              ASSOC-ATTR-POLICY                 April 2016


8.  IANA Considerations

8.1.  Association object Type Indicators

   This document defines the following new association type originally
   defined in [I-D.ietf-pce-association-group].

   Value     Name                        Reference
   TBD1      Attribute Association Type  [This I.D.]
   TBD2      Policy Association Type     [This I.D.]

8.2.  PCEP TLV Type Indicators

   This document defines the following new PCEP TLV; IANA is requested
   to make the following allocations from this registry.
   http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-
   indicators

   Value     Name                        Reference
   TBD3      ATTRIBUTE-OBJECT-TLV        [This I.D.]

9.  Manageability Considerations

9.1.  Control of Function and Policy

   An operator MUST BE allowed to configure the attribute associations
   at PCEP peers and associate it with the LSPs.

9.2.  Information and Data Models

   [RFC7420] describes the PCEP MIB, there are no new MIB Objects for
   this document.

9.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].

9.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].







Dhody & Wu              Expires October 21, 2016                [Page 9]


Internet-Draft              ASSOC-ATTR-POLICY                 April 2016


9.5.  Requirements On Other Protocols

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

9.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].

10.  Acknowledgments

   A special thanks to author of [I-D.ietf-pce-association-group], this
   document borrow some of the text from it.

11.  References

11.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,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655,
              DOI 10.17487/RFC4655, August 2006,
              <http://www.rfc-editor.org/info/rfc4655>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <http://www.rfc-editor.org/info/rfc5440>.

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

   [I-D.ietf-pce-association-group]
              Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
              Zhang, X., and Y. Tanaka, "PCEP Extensions for
              Establishing Relationships Between Sets of LSPs", draft-
              ietf-pce-association-group-00 (work in progress), November
              2015.






Dhody & Wu              Expires October 21, 2016               [Page 10]


Internet-Draft              ASSOC-ATTR-POLICY                 April 2016


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

11.2.  Informative References

   [RFC5394]  Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
              "Policy-Enabled Path Computation Framework", RFC 5394,
              DOI 10.17487/RFC5394, December 2008,
              <http://www.rfc-editor.org/info/rfc5394>.

   [RFC6805]  King, D., Ed. and A. Farrel, Ed., "The Application of the
              Path Computation Element Architecture to the Determination
              of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
              DOI 10.17487/RFC6805, November 2012,
              <http://www.rfc-editor.org/info/rfc6805>.

   [RFC7420]  Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
              Hardwick, "Path Computation Element Communication Protocol
              (PCEP) Management Information Base (MIB) Module",
              RFC 7420, DOI 10.17487/RFC7420, December 2014,
              <http://www.rfc-editor.org/info/rfc7420>.

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

   [I-D.ietf-pce-pce-initiated-lsp]
              Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
              Extensions for PCE-initiated LSP Setup in a Stateful PCE
              Model", draft-ietf-pce-pce-initiated-lsp-05 (work in
              progress), October 2015.

   [I-D.ietf-teas-actn-requirements]
              Lee, Y., Dhody, D., Belotti, S., Pithewan, K., and D.
              Ceccarelli, "Requirements for Abstraction and Control of
              TE Networks", draft-ietf-teas-actn-requirements-02 (work
              in progress), April 2016.

   [I-D.leedhody-pce-vn-association]
              Lee, Y., Dhody, D., and D. Ceccarelli, "PCEP Extensions
              for Establishing Relationships Between Sets of LSPs and
              Virtual Networks", draft-leedhody-pce-vn-association-00
              (work in progress), February 2016.





Dhody & Wu              Expires October 21, 2016               [Page 11]


Internet-Draft              ASSOC-ATTR-POLICY                 April 2016


Appendix A.  Contributor Addresses

   Xian Zhang
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R.China

   EMail: zhang.xian@huawei.com

   Udayasree Palle
   Huawei Technologies
   Divyashree Techno Park, Whitefield
   Bangalore, Karnataka  560066
   INDIA

   EMail: udayasree.palle@huawei.com


Authors' Addresses

   Dhruv Dhody
   Huawei Technologies
   Divyashree Techno Park, Whitefield
   Bangalore, Karnataka  560066
   India

   EMail: dhruv.ietf@gmail.com


   Qin Wu
   Huawei Technologies
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   EMail: sunseawq@huawei.com














Dhody & Wu              Expires October 21, 2016               [Page 12]