Skip to main content

The China Mobile, Huawei, and ZTE BNG Simple Control and User Plane Separation Protocol (S-CUSP)
draft-chz-simple-cu-separation-bng-protocol-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8772.
Authors Shujun Hu , Donald E. Eastlake 3rd , Mach Chen , Fengwei Qin , Zhenqiang Li , Tee Mong Chua
Last updated 2019-06-24 (Latest revision 2019-06-14)
Replaces draft-cuspdt-rtgwg-cu-separation-bng-protocol
RFC stream (None)
Formats
IETF conflict review conflict-review-chz-simple-cu-separation-bng-protocol, conflict-review-chz-simple-cu-separation-bng-protocol, conflict-review-chz-simple-cu-separation-bng-protocol, conflict-review-chz-simple-cu-separation-bng-protocol, conflict-review-chz-simple-cu-separation-bng-protocol, conflict-review-chz-simple-cu-separation-bng-protocol
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Became RFC 8772 (Informational)
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-chz-simple-cu-separation-bng-protocol-02
Network Working Group                                             X. Liu
Internet-Draft                                            Volta Networks
Intended status: Standards Track                              I. Bryskin
Expires: April 27, 2022                                       Individual
                                                               V. Beeram
                                                                 T. Saad
                                                        Juniper Networks
                                                                 H. Shah
                                                                   Ciena
                                                            S. Litkowski
                                                                   Cisco
                                                        October 24, 2021

     YANG Data Model for SR and SR TE Topologies on MPLS Data Plane
                   draft-ietf-teas-yang-sr-te-topo-11

Abstract

   This document defines a YANG data model for Segment Routing (SR)
   topology and Segment Routing (SR) traffic engineering (TE) topology,
   using MPLS data plane.

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 https://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 April 27, 2022.

Copyright Notice

   Copyright (c) 2021 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
   (https://trustee.ietf.org/license-info) in effect on the date of

Liu, et al.              Expires April 27, 2022                 [Page 1]
Internet-Draft            YANG SR MPLS Topology             October 2021

   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.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Tree Diagrams . . . . . . . . . . . . . . . . . . . . . .   3
     1.3.  Prefixes in Data Node Names . . . . . . . . . . . . . . .   3
   2.  Modeling Considerations . . . . . . . . . . . . . . . . . . .   4
     2.1.  Segment Routing (SR) MPLS Topology  . . . . . . . . . . .   4
     2.2.  Segment Routing (SR) MPLS TE Topology . . . . . . . . . .   4
     2.3.  Relations to ietf-segment-routing . . . . . . . . . . . .   7
     2.4.  Topology Type Modeling  . . . . . . . . . . . . . . . . .   7
     2.5.  Topology Attributes . . . . . . . . . . . . . . . . . . .   7
     2.6.  Node Attributes . . . . . . . . . . . . . . . . . . . . .   7
     2.7.  Link Attributes . . . . . . . . . . . . . . . . . . . . .   9
   3.  Model Structure . . . . . . . . . . . . . . . . . . . . . . .  10
   4.  YANG Module . . . . . . . . . . . . . . . . . . . . . . . . .  11
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  23
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  25
   Appendix A.  Companion YANG Model for Non-NMDA Compliant
                Implementations  . . . . . . . . . . . . . . . . . .  26
     A.1.  SR MPLS Topology State Module . . . . . . . . . . . . . .  26
   Appendix B.  Data Tree Example  . . . . . . . . . . . . . . . . .  29
     B.1.  SR MPLS Topology with TE Not Enabled  . . . . . . . . . .  30
     B.2.  SR MPLS Topology with TE Enabled  . . . . . . . . . . . .  37
   Appendix C.  Contributors . . . . . . . . . . . . . . . . . . . .  47
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  47

1.  Introduction

   This document defines a YANG [RFC7950] data model for describing the
   presentations of Segment Routing (SR) topology and Segment Routing
   (SR) traffic engineering (TE) topology.  The version of the model
   limits the transport type to an MPLS dataplane.

Liu, et al.              Expires April 27, 2022                 [Page 2]
Internet-Draft            YANG SR MPLS Topology             October 2021

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "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.

   The following terms are defined in [RFC7950] and are not redefined
   here:

   o  augment

   o  data model

   o  data node

1.2.  Tree Diagrams

   Tree diagrams used in this document follow the notation defined in
   [RFC8340].

1.3.  Prefixes in Data Node Names

   In this document, names of data nodes, actions, and other data model
   objects are often used without a prefix, as long as it is clear from
   the context in which YANG module each name is defined.  Otherwise,
   names are prefixed using the standard prefix associated with the
   corresponding YANG module, as shown in Table 1.

   +--------+--------------------------+-------------------------------+
   | Prefix | YANG module              | Reference                     |
   +--------+--------------------------+-------------------------------+
   | nw     | ietf-network             | [RFC8345]                     |
   | nt     | ietf-network-topology    | [RFC8345]                     |
   | l3t    | ietf-l3-unicast-topology | [RFC8346]                     |
   | sr-cmn | ietf-segment-routing-    | [RFC9020]                     |
   |        | common                   |                               |
   | tet    | ietf-te-topology         | [RFC8795]                     |
   | tet-   | ietf-te-topology-packet  | [I-D.ietf-teas-yang-l3-te-top |
   | pkt    |                          | o]                            |
   +--------+--------------------------+-------------------------------+

             Table 1: Prefixes and Corresponding YANG Modules

Liu, et al.              Expires April 27, 2022                 [Page 3]
Internet-Draft            YANG SR MPLS Topology             October 2021

2.  Modeling Considerations

2.1.  Segment Routing (SR) MPLS Topology

   The Layer 3 network topology model is discussed in [RFC8346].  The
   Segment Routing (SR) MPLS topology model proposed in this document
   augments and uses the ietf-l3-unicast-topology module defined in
   [RFC8346].  SR MPLS related attributes are covered in the ietf-sr-
   mpls-topology module.

               +------------------------------+
               |   Layer 3 Network Topology   |
               |   ietf-l3-unicast-topology   |
               +---------------^--------------+
                               |
                               |
                               |
                               |
                  +------------^-----------+
                  |    SR MPLS Topology    |
                  | ietf-sr-mpls-topology  |
                  +------------------------+

                  Figure 1: SR MPLS topology augmentation

2.2.  Segment Routing (SR) MPLS TE Topology

   A Segment Routing (SR) MPLS TE topology is an instance of SR MPLS
   topology with TE enabled.  In order to instantiate an SR MPLS TE
   topology, the ietf-sr-mpls-topology module defined in this document
   can be used together with the ietf-te-topology module defined in
   [RFC8795] and the ietf-te-topology-packet module defined in
   [I-D.ietf-teas-yang-l3-te-topo].  All these modules directly or
   indirectly augment the ietf-network-topology module defind in
   [RFC8345], as shown in Figure 2.

Liu, et al.              Expires April 27, 2022                 [Page 4]
Internet-Draft            YANG SR MPLS Topology             October 2021

                        +---------------------------+
                        |    Network Topology       |
                        |  ietf-network-topology    |
                        +-^-----------------------^-+
                         /                         \
                        /                           \
                       /                             \
                      /                               \
        +-------------^-------------+   +-------------^-------------+
        | Layer 3 Unicast Topology  |   |        TE Topology        |
        | ietf-l3-unicast-topology  |   |      ietf-te-topology     |
        +-------------^-------------+   +-------------^-------------+
                      |                               |
                      |                               |
                      |                               |
                      |                               |
        +-------------^-------------+   +-------------^-------------+
        |     SR MPLS Topology      |   |     TE Packet Topology    |
        |   ietf-sr-mpls-topology   |   |  ietf-te-topology-packet  |
        +---------------------------+   +---------------------------+

          Figure 2: SR TE topology instance inheritance relations

   Figure 3 shows the data structure of an SR TE topology instance.
   Because of the augmentation relationships shown in Figure 2, a data
   instance of an SR MPLS TE topology contains the capabilities from all
   these modules, so that the data includes the attributes from ietf-
   network-topology, ietf-l3-unicast-topology, ietf-sr-mpls-topology,
   ietf-te-topology, and ietf-te-topology-packet.

Liu, et al.              Expires April 27, 2022                 [Page 5]
Internet-Draft            YANG SR MPLS Topology             October 2021

       +--------------------------------------------------------+
       | ietf-network-topology:                                 |
       |   network-id (key)                                     |
       |   network-types: {                                     |
       |     l3-unicast-topology: {                             |
       |       sr-mpls{}                                        |
       |     }                                                  |
       |     te-topology: {                                     |
       |       packet{}                                         |
       |     }                                                  |
       |   }                                                    |
       |   <other network topology attributes>                  |
       +-----------------------------+--------------------------+
       | ietf-l3-unicast-topology:   | ietf-te-topology:        |
       |   <L3 unicast attributes>   |   <TE attributes>        |
       +-----------------------------+--------------------------+
       | ietf-sr-mpls-topology:      | ietf-te-topology-packet: |
       |   <SR MPLS attributes>      |   <TE packet attributesINTERNET-DRAFT                                           Simple BNG CUSP

                                          about a BNG subscriber.
       4   IPv4 Subscriber                Carries the IPv4 address of a
                                          BNG subscriber.
       5   IPv6 Subscriber                Carries the IPv6 address of a
                                          BNG subscriber.
       6   Subscriber Policy              Carries the policy information
                                          applied to a BNG subscriber.
       7   IPv4 Routing                   Carries the IPv4 network
                                          routing information.
       8   IPv6 Routing                   Carries the IPv6 network
                                          routing information.
       9   IPv4 Static Subscriber Detect  Carries the IPv4 static
                                          subscriber detect information.
      10   IPv6 Static Subscriber Detect  Carries the IPv6 static
                                          subscriber detect information.
      11   L2TP-LAC Subscriber            Carries the L2TP LAC
                                          subscriber information.
      12   L2TP-LNS Subscriber            Carries the L2TP LNS
                                          subscriber information.
      13   L2TP-LAC-Tunnel                Carries the L2TP LAC tunnel
                                          subscriber information.
      14   L2TP-LNS-Tunnel                Carries the L2TP LNS tunnel
                                          subscriber information.
      15   Subscriber CGN Port Range      Carries the public IPv4
                                          address and related port range
                                          of a BNG subscriber.
   16-99    unassigned                     -
     100   Hello                          Used for version and Keep
                                          Alive timers negotiation.
     101   Error Information              Carried in the Ack of the
                                          control message.  Carries the
                                          processing result, success, or
                                          error.
     102   Keep Alive                     Carried in the Hello message
                                          for Keep Alive timers
                                          negotiation.
   103-199  unassigned                     -
     200   Interface Status               Interfaces status reported by
                                          the UP including physical
                                          interfaces, sub-interfaces,
                                          trunk interfaces, and tunnel
                                          interfaces.
     201   Board Status                   Board information reported by
                                          the UP including the board
                                          type and in-position status.
   202-299  unassigned                     -
     300   Subscriber Traffic Statistics  User traffic statistics.
     301   Subscriber Detection Results   User detection information.
     302   Update Response                The processing result of a
                                          subscriber session update.

Hu, et al                                                     [Page 116]
INTERNET-DRAFT                                           Simple BNG CUSP

   303-299  unassigned                     -
     400   Address Allocation Request     Request address allocation.
     401   Address Allocation Response    Address allocation response.
     402   Address Renewal Request        Request for address lease
                                          renewal.
     403   Address Renewal Response       Response to a request for
                                          extending an IP address lease.
     404   Address Release Request        Request to release the
                                          address.
     405   Address Release Response       Ack of a message releasing an
                                          IP address.
   406-1023 unassigned                     -
    1024   Vendor                         As implemented by vendor.
   1039-4095 unassigned                    -

9.3.  TLV Operation Codes

   TLV operation codes appear in the Oper field in the header of some
   TLVs. See Section 7.1.

      Code  Operation
      ----  ----------
         0   - reserved
         1  Update
         2  Delete
      3-15   - unassigned

Hu, et al                                                     [Page 117]
INTERNET-DRAFT                                           Simple BNG CUSP

9.4.  Sub-TLV Types

   See Section 7.3.

       Type   Name                Section of this document
       ----  ------------------   ------------------------
           0    - reserved
           1   VRF Name             7.3.1.
           2   Ingress-QoS-Profile  7.3.1.
           3   Egress-QoS-Profile   7.3.1.
           4   User-ACL-Policy      7.3.1.
           5   Multicast-ProfileV4  7.3.1.
           6   Multicast-ProfileV6  7.3.1.
           7   Ingress-CAR          7.3.2.
           8   Egress-CAR           7.3.3.
           9   NAT-Instance         7.3.1.
          10   Pool-Name            7.3.1.
          11   If-Desc              7.3.4.
          12   IPv6-Address List    7.3.5.
          13   Vendor               7.3.6.
      12-64534  - unassigned
       65535    - reserved

9.5.  Error Codes

    Value     Name             Remarks
   -------   -------          --------
        0    Success          Success

        1    Fail             Malformed message received.
        2    TLV-Unknown      One or more of the TLVs was not
                              understood.
        3    TLV-Length       The TLV length is abnormal.
    4-999     - unassigned    Unassigned basic error codes.
     1000     - reserved
     1001    Version-Mismatch The version negotiation fails. Terminate.
                              The subsequent service processes
                              corresponding to the UP are suspended.
     1002    Keepalive Error  The keepalive negotiation fails.
     1003    Timer Expires    The establishment timer expired.
   1004-1999  - unassigned    Unassigned error codes for version
                              negotiation.
     2000     - reserved
     2001    Synch-NoReady    The data to be smoothed is not ready.
     2002    Synch-Unsupport  The request for smooth data is not
                              supported.
   2003-2999  - unassigned    Unassigned data synchronization error
                              codes.

Hu, et al                                                     [Page 118]
INTERNET-DRAFT                                           Simple BNG CUSP

     3000     - reserved
     3001    Pool-Mismatch    The corresponding address pool cannot be
                              found.
     3002    Pool-Full        The address pool is fully allocated and no
                              address segment is available.
     3003    Subnet-Mismatch  The address pool subnet cannot be found.
     3004    Subnet-Conflict  Subnets in the address pool have been
                              classified into other clients.
   3005-3999  - unassigned    Unassigned error codes for address
                              allocation.
     4000     - reserved
     4001    Update-Fail-No-Res  The forwarding table fails to be
                              delivered because the forwarding resources
                              are insufficient.
     4002    QoS-Update-Success  The QoS policy takes effect.
     4003    QoS-Update-Sq-Fail  Failed to process the queue in the QoS
                              policy.
     4004    QoS-Update-CAR-Fail  Processing of the CAR in the QoS
                              policy fails.
     4005    Statistic-Fail-No-Res  Statistics processing failed due to
                              insufficient statistics resources.
   4006-4999  - unassigned forwarding table delivery error codes.

   5000-4294967295 - reserved

Hu, et al                                                     [Page 119]
INTERNET-DRAFT                                           Simple BNG CUSP

10.  IANA Considerations

   This document requires no IANA actions.

Hu, et al                                                     [Page 120]
INTERNET-DRAFT                                           Simple BNG CUSP

11.  Security Considerations

   The Service, Control, and Management Interfaces between the CP and UP
   might be across the general Internet or other hostile environment.
   The ability of an adversary to block or corrupt messages or introduce
   spurious messages on any one or more of these interfaces would give
   the adversary the ability to stop subscribers from accessing network
   services, disrupt existing subscriber sessions, divert traffic, mess
   up accounting statistics, and generally cause havoc. Damage would not
   necessarily be limited to one or a few subscribers but could disrupt
   routing or deny service to one or more instances of the CP or
   otherwise cause extensive interference. If the adversary knows the
   details of the UP equipment and its forwarding rule capabilities, the
   adversary may be able to cause a copy of all user data to be sent to
   an address of the adversary's choosing, thus enabling eavesdropping.

   Thus, appropriate protections MUST be implemented to provide
   integrity, authenticity, and secrecy of traffic over those
   interfaces. Whether such protection is used is a network operator
   decision.  See [RFC6241] for Management Interface / NETCONF security.
   Security on the Service Interface is dependent on the tunneling
   protocol used which is out of scope for this document.  Security for
   the Control Interface, over which the S-CUSP protocol flows, is
   further discussed below.

   S-CUSP messages do not provide security. Thus, if these messages are
   exchanged in an environment where security is a concern, that
   security MUST be provided by another protocol such as TLS 1.3
   [RFC8446] or IPSEC. TLS 1.3 is the mandatory to implement protocol
   for interoperability. However, such security protocols need not
   always be used and lesser security precautions might be appropriate
   because, in some cases, the communication between the CP and UP is in
   a benign environment.

Hu, et al                                                     [Page 121]
INTERNET-DRAFT                                           Simple BNG CUSP

Contributors

      Zhouyi Yu
      Huawei Technologies

      Email: yuzhouyi@huawei.com

      Chengguang Niu
      Huawei Technologies

      Email: chengguang.niu@huawei.com

      Zitao Wang
      Huawei Technologies

      Email: wangzitao@huawei.com

      Jun Song
      Huawei Technologies

      Email: song.jun@huawei.com

      Dan Meng
      H3C Technologies
      No.1 Lixing Center
      No.8 guangxun south street, Chaoyang District,
      Beijing, 100102
      China

      Email: mengdan@h3c.com

      Hanlei Liu
      H3C Technologies
      No.1 Lixing Center
      No.8 guangxun south street, Chaoyang District,
      Beijing, 100102
      China

      Email: hanlei_liu@h3c.com

Hu, et al                                                     [Page 122]
INTERNET-DRAFT                                           Simple BNG CUSP

Normative References

   [RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC
             20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-
             editor.org/info/rfc20>.

   [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
             DOI 10.17487/RFC0793, September 1981, <https://www.rfc-
             editor.org/info/rfc793>.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, DOI
             10.17487/RFC2119, March 1997, <https://www.rfc-
             editor.org/info/rfc2119>.

   [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.,
             and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC
             2661, DOI 10.17487/RFC2661, August 1999, <https://www.rfc-
             editor.org/info/rfc2661>.

   [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
             "Remote Authentication Dial In User Service (RADIUS)", RFC
             2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-
             editor.org/info/rfc2865>.

   [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
             and A. Bierman, Ed., "Network Configuration Protocol
             (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
             <https://www.rfc-editor.org/info/rfc6241>.

   [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
             Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
             2017, <https://www.rfc-editor.org/info/rfc8174>.

Hu, et al                                                     [Page 123]
INTERNET-DRAFT                                           Simple BNG CUSP

Informative References

   [802.1Q] IEEE, "IEEE Standard for Local and metropolitan area
             networks / Bridges and Bridged Networks", IEEE Std
             802.1Q-2014, 3 November 2013.

   [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD
             51, RFC 1661, DOI 10.17487/RFC1661, July 1994,
             <https://www.rfc-editor.org/info/rfc1661>.

   [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
             DOI 10.17487/RFC2131, March 1997, <https://www.rfc-
             editor.org/info/rfc2131>.

   [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
             and R. Wheeler, "A Method for Transmitting PPP Over
             Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, February
             1999, <https://www.rfc-editor.org/info/rfc2516>.

   [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color
             Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999,
             <https://www.rfc-editor.org/info/rfc2698>.

   [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
             Address Translator (Traditional NAT)", RFC 3022, DOI
             10.17487/RFC3022, January 2001, <https://www.rfc-
             editor.org/info/rfc3022>

   [RFC3336] Thompson, B., Koren, T., and B. Buffam, "PPP Over
             Asynchronous Transfer Mode Adaptation Layer 2 (AAL2)", RFC
             3336, DOI 10.17487/RFC3336, December 2002,
             <https://www.rfc-editor.org/info/rfc3336>.

   [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used
             to Form Encoding Rules in Various Routing Protocol
             Specifications", RFC 5511, DOI 10.17487/RFC5511, April
             2009, <https://www.rfc-editor.org/info/rfc5511>.

   [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and
             IETF Protocol and Documentation Usage for IEEE 802
             Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042,
             October 2013, <https://www.rfc-editor.org/info/rfc7042>.

   [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
             L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
             eXtensible Local Area Network (VXLAN): A Framework for
             Overlaying Virtualized Layer 2 Networks over Layer 3
             Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
             <https://www.rfc-editor.org/info/rfc7348>.

Hu, et al                                                     [Page 124]
INTERNET-DRAFT                                           Simple BNG CUSP

   [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
             Code: The Implementation Status Section", BCP 205, RFC
             7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-
             editor.org/info/rfc7942>.

   [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
             Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
             <https://www.rfc-editor.org/info/rfc8446>.

   [TR-384] Broadband Forum, "Cloud Central Office Reference
             Architectural Framework", BBF TR-384, 2018.

Hu, et al                                                     [Page 125]
INTERNET-DRAFT                                           Simple BNG CUSP

Authors' Addresses

      Shujun Hu
      China Mobile
      32 Xuanwumen West Ave, Xicheng District
      Beijing, Beijing  100053
      China

      Email: hushujun@chinamobile.com

      Donald Eastlake, 3rd
      Futurewei Technologies
      1424 Pro Shop Court
      Davenport, FL  33896
      USA

      Phone: +1-508-333-2270
      Email: d3e3e3@gmail.com

      Mach (Guoyi) Chen
      Huawei Technologies
      Huawei Bldg., No. 156 Beiqing Road
      Beijing 100095 China

      Email: mach.chen@huawei.com

      Fengwei Qin
      China Mobile
      32 Xuanwumen West Ave, Xicheng District
      Beijing, Beijing  100053
      China

      Email: qinfengwei@chinamobile.com

      Zhenqiang Li
      China Mobile
      32 Xuanwumen West Ave, Xicheng District
      Beijing, Beijing  100053
      China

      Email: lizhenqiang@chinamobile.com

Hu, et al                                                     [Page 126]
INTERNET-DRAFT                                           Simple BNG CUSP

      Tee Mong Chua
      Singapore Telecommunications Limited
      31 Exeter Road, #05-04 Comcentre Podium Block
      Singapore City  239732
      Singapore

      Email: teemong@singtel.com

Hu, et al                                                     [Page 127]
INTERNET-DRAFT                                           Simple BNG CUSP

Copyright, Disclaimer, and Additional IPR Provisions

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

Hu, et al                                                     [Page 128]