BANANA N. Leymann Internet Draft C. Heidemann Intended Category: Proposed Standard Deutsche Telekom AG M. Zhang B. Sarikaya Huawei M. Cullen Painless Security Expires: November 26, 2017 May 25, 2017 BANdwidth Aggregation for interNet Access (BANANA) The Control Protocol of Bonding Tunnels draft-leymann-banana-signaling-00.txt Abstract There is an emerging demand for solutions to bond multiple access links to provide subscribers with redundancy and load-sharing across these access links. BANdwidth Aggregation for interNet Access (BANANA) will specify such solutions. In this document, a control protocol is specified to deliver configuration and control information between two peering BANANA boxes. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Leymann, et al. Expires November 25, 2017 [Page 1] INTERNET-DRAFT BANANA Signaling May 25, 2017 Copyright and License 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 2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 3 3. The Single Operator Scenario . . . . . . . . . . . . . . . . . 5 4. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Control Protocol Specification . . . . . . . . . . . . . . . . 7 5.1. Message Formats . . . . . . . . . . . . . . . . . . . . . 7 5.2. Establishment of Bonding Tunnels . . . . . . . . . . . . . 10 6. The Edge to Edge Scenario . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction Service Providers used to provide subscribers with separate access to their multiple networks. It has become desirable to bond access links to these networks together to offer access service to subscribers. When the traffic volume exceeds the bandwidth of the first connection, the excess amount can be offloaded to a secondary connection. So bonding service is able to provide subscribers with increased access capacity and improved reliability. This memo will mainly work two scenarios out: the single operator scenario and the edge to edge scenario. There would be mainly implementation issues to make BANANA be applicable to more scenarios. For the single-operator scenario, the local BANANA box is a Customer Leymann, et al. Expires November 25, 2017 [Page 2] INTERNET-DRAFT BANANA Signaling May 25, 2017 Premises Equipment (CPE) device initiating the two connections. The remote BANANA box resides in the provider's networks to terminate these bonded connections. For the edge to edge scenario, the two peering BANANA boxes are two CPE devices which might be operated by different providers. This document specifies the control protocol between the two BANANA boxes. This control protocol adopts GRE (Generic Routing Encapsulation [RFC2890]) since GRE is widely supported in various networks. Approaches specified in this document might also be used by other tunneling technologies to achieve tunnel bonding. However, such variants are out of scope for this document. For each heterogeneous connection between the two BANANA boxes, one GRE tunnel is set up. The local and remote BANANA box, respectively, serve as the common termination point of the tunnels at both ends. Those GRE tunnels are bonded together to form a logical IP link for the subscriber. This provides an overlay: the users' IP packets (inner IP) are encapsulated in GRE, which is in turn carried over IP (outer IP). A tunnel bonding solution of BANANA may support more than two tunnels between the two BANANA boxes though the reference topologies in this memo choose to use two tunnels between the two BANANA boxes to depict such a solution. 2. Acronyms and Terminology GRE: Generic Routing Encapsulation [RFC2890]. BRAS: Broadband Remote Access Server. Routes traffic to and from broadband remote access devices such as Digital Subscriber Line Access Multiplexers (DSLAMs) on an Internet Service Provider's (ISP's) network. PGW: Packet Data Network Gateway. In the Long Term Evolution (LTE) architecture for the Evolved Packet Core (EPC), acts as an anchor for user-plane mobility. PDP: Packet Data Protocol. A packet transfer protocol used in wireless GPRS (General Packet Radio Service) / HSDPA (High-Speed Downlink Packet Access) networks. PPPoE: Point-to-Point over Ethernet. A network protocol for encapsulating PPP frames inside Ethernet frames. DNS: Domain Name System. A hierarchical distributed naming system for computers, services, or any resource connected to the Internet Leymann, et al. Expires November 25, 2017 [Page 3] INTERNET-DRAFT BANANA Signaling May 25, 2017 or a private network. DHCP: Dynamic Host Configuration Protocol. A standardized network protocol used on Internet Protocol (IP) networks for dynamically distributing network configuration parameters, such as IP addresses for interfaces and services. 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]. Leymann, et al. Expires November 25, 2017 [Page 4] INTERNET-DRAFT BANANA Signaling May 25, 2017 3. The Single Operator Scenario DNS server branch router +--------------+ +-----------+ +--+ | | | | ,,, ,,,,,, | | | +-+ | | DHCP | , ,, , |A6|------------| | | |+-+ IP pool| , , | | | | | F--Tunnel 1--| | | ,, ,, | | | +-+ |C| | ||R| ---------I , | | | |N| | | S--Tunnel 2--| | | ,, ,, |A4|---A1---|A|-| | | |+-+ | ,,,,,,,,,,, | | | |T| +-+ | | | Internet +--+ |DHCP +-+ | | | Host |IP pool | | | +--------------+ +-----------+ local remote BANANA box BANANA box A6: The endpoint for the IPv6 address that is used for the BANANA service by the Host. A4: The endpoint for the IPv4 address that is used for the BANANA service by the Host. C: The service endpoint of the bonding service at the local BANANA box. IP address or IP prefix of C is assigned by the DHCP from a pool of IP addresses maintained on the remote BANANA box. A1: The endpoint of the Gateway on the same Local Area Network (LAN) as the Host. The pre-configured IP address of A1 will be translated to the IP address of C by the Network Address Translator (NAT). F: The local endpoint of the first tunnel (Tunnel 1) at the local BANANA box. S: The local endpoint of the secondary tunnel (Tunnel 2) at the local BANANA box. R: The common remote endpoint for Tunnel 1 and Tunnel 2 at the remote BANANA box. The DNS server will resolve an URL provisioned by the Service Provider to be the IP address of R. I: The endpoint of the destination in the Internet. Figure 3.1: Tunnel bonding for a single operator If a Service Provider runs multiple networks, subscribers are eager to use those networks simultaneously for increased access capacity rather than just using a single network. As shown by the reference topology in Figure 3.1, the subscriber expects a significantly higher Leymann, et al. Expires November 25, 2017 [Page 5] INTERNET-DRAFT BANANA Signaling May 25, 2017 access bandwidth from the bonding connection than from just the first connection. In other words, when the traffic volume exceeds the bandwidth of the first connection, the excess amount may be offloaded to the secondary connection. One tunnel is established per-connection between the two BANANA boxes (see Figure 3.1). These tunnels are bonded together as if there is a single IP link provided between the two boxes for the subscriber who buys the local BANANA box. Compared to per-flow load balancing mechanisms which are widely used nowadays, BANANA MUST support per-packet offloading approach. For per-flow load-balancing, the maximum bandwidth that may be used by a traffic flow is the bandwidth of an individual connection. While for per-packet offloading, a single flow may use the added-up bandwidth of all the connections. Although this memo depicts the tunnel bonding solution using reference topologies (see also Section 6) with two GRE tunnels between the two BANANA boxes, a tunnel bonding solution can support more than two tunnels between the two BANANA boxes. 4. Addressing When the Host boots up, IP addresses of A4 and/or A6 will be assigned by the DHCP from a pool of IP addresses maintained on the local BANANA box. The Gateway IP addresses of A1 is locally configured and will be translated into the IP address of C which is assigned by the DHCP from a pool of IP addresses maintained on the remote BANANA box. IPv6 address of A6 has the same prefix as C so that NAT function is unnecessary. The DHCP message that carries the IP address of C will be encapsulated as a GRE data packet ([BANANA-encap]) after Tunnel 1 is established. When the local BANANA box boots up, IP addresses of F and S will be automatically assigned by network devices connected to the local BANANA box. As examples, if this network device is a Broadband Remote Access Server (BRAS), the local BANANA box gets an IP address through the Point-to-Point Protocol over Ethernet (PPPoE). If this network device is a Packet Data Network Gateway (PGW), the local BANANA box gets an IP address through the Packet Data Protocol (PDP). In order to support automatic establishment of GRE tunnels, the IP address of F or S needs to be carried by the control protocol from the local BANANA box to the remote BANANA box. The domain name of a remote BANANA box may be configured or obtained via the Wide Area Network (WAN) interface of the first or secondary connection based on gateway configuration protocols such as [TR-069]. Leymann, et al. Expires November 25, 2017 [Page 6] INTERNET-DRAFT BANANA Signaling May 25, 2017 The resolution of the remote BANANA box's domain name is requested via the WAN interface of the first or secondary connection. The Domain Name System (DNS) server will reply with the IP address of R which is assigned by DHCP from a pool of IP addresses maintained on the remote BANANA box. A Service Provider might deploy multiple remote BANANA boxes in one site and place a branch router in front of these remote BANANA boxes. The DNS server will resolve the URL to a pre-configured IP address of this branch router instead of the IP address of R. In this way, the tunnel setup request from the local box will reach this branch router instead of R. This branch router will adopt anycast mechanism to achieve load balancing and direct the tunnel setup request to one of the remote BANANA boxes. For this case, the IP address of R needs to be carried by the control protocol from the remote BANANA box to the local BANANA box for the purpose of automatic establishment of GRE tunnels. 5. Control Protocol Specification The control protocol of BANANA is designed to exchange configuration and control information between the two BANANA boxes, such as IP prefixes of local links (see Section 4), the link properties and status and the information needed by the encapsulations. 5.1. Message Formats Messages of the control protocol are delivered as GRE encapsulated packets and routed via the same GRE tunnels as GRE data packets. All control messages are sent in network byte order (high-order bytes first). The GRE Protocol Type field is used to distinguish control packets from GRE data packets. The new GRE Protocol Type (0xB7EA) is allocated for this purpose. GRE packets with a Protocol Type that equals to this number will be consumed by the receiving BANANA box rather than forward further. The standard GRE header as per [RFC2890] with Checksum Present bit and Sequence Number Present bit set to zero and Key Present bit set to one is used in this memo. This means the Checksum, the Sequence Number and the Reserved1 fields are not present. So, the format of the GRE header for control messages of is as follows: Leymann, et al. Expires November 25, 2017 [Page 7] INTERNET-DRAFT BANANA Signaling May 25, 2017 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| |1|0| Reserved0 | Ver | Protocol Type 0xB7EA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The remote BANANA box generates a random number to be carried as the Key field of each control message by the local BANANA box. Except the first GRE Tunnel Setup Request message, the Key field of all control messages originated by the local BANANA box MUST be set to this random number. The remote BANANA box uses the value of the Key to authenticate the local BANANA box. The general format of the entire control message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| |1|0| Reserved0 | Ver | Protocol Type 0xB7EA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |MsgType|T-Type | | +-+-+-+-+-+-+-+-+ Attributes + ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5.1: Format of Control Messages of GRE Tunnel Bonding o MsgType (4 bits) Message Type. The control message family contains the following six types of control messages (not including "Reserved"): Control Message Family Type ========================== ========= GRE Tunnel Setup Request 1 GRE Tunnel Setup Accept 2 GRE Tunnel Setup Deny 3 GRE Tunnel Hello 4 GRE Tunnel Tear Down 5 GRE Tunnel Notify 6 Reserved 0, 7-15 - GRE Tunnel Setup Request The local BANANA box uses the GRE Tunnel Setup Request message to request that the remote BANANA box establishes the GRE tunnels. Leymann, et al. Expires November 25, 2017 [Page 8] INTERNET-DRAFT BANANA Signaling May 25, 2017 It is sent out from the local BANANA box's F and S interfaces (see Figure 3.1). - GRE Tunnel Setup Accept The remote BANANA box uses the GRE Tunnel Setup Accept message as the response to the GRE Tunnel Setup Request message. This message indicates the acceptance of the tunnel establishment and carries parameters of the GRE tunnels. - GRE Tunnel Setup Deny The remote BANANA MUST send the GRE Tunnel Setup Deny message to the local BANANA box if the GRE Tunnel Setup Request from this local BANANA box is denied. The local BANANA box MUST terminate the GRE tunnel setup process as soon as it receives the GRE Tunnel Setup Deny message. - GRE Tunnel Hello After the first or the second GRE tunnel is established (see Figure 3.1), the local BANANA box begins to periodically send out GRE Tunnel Hello messages via the tunnel; the remote BANANA box acknowledges the local BANANA box's messages by returning GRE Tunnel Hello messages received from the local BANANA box. This continues until the tunnel is terminated. - GRE Tunnel Tear Down The remote BANANA box can terminate a GRE tunnel by sending the GRE Tunnel Tear Down message to the local BANANA box via the tunnel. After receiving the GRE Tunnel Tear Down message, the local BANANA removes the IP address of R (see Figure 3.1). - GRE Tunnel Notify The two BANANA boxes use the GRE Tunnel Notify message, which is transmitted through either the first or the second GRE tunnel, to notify each other about their status regarding the two GRE tunnels, the information for the bonding tunnels, the actions that need to be taken, etc. Normally, the receiver just sends the received attributes back as the acknowledgement for each GRE Tunnel Notify message. If the size of the attribute is too large, an acknowledgement attribute for it need to be defined. o T-Type (4 bits) Tunnel Type. Set to 0001 if the control message is sent via the first GRE tunnel. Set to 0010 if the control message is sent via the second GRE tunnel. Values 0000 and values from 0011 through 1111 are reserved for future use and MUST be ignored on receipt. Leymann, et al. Expires November 25, 2017 [Page 9] INTERNET-DRAFT BANANA Signaling May 25, 2017 o Attributes The Attributes field includes the attributes that need to be carried in the control message. Each Attribute has the following format: +-+-+-+-+-+-+-+-+ |Attribute Type | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Value ~ (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Attribute Type The Attribute Type specifies the type of the attribute. - Attribute Length Attribute Length indicates the length of the Attribute Value in bytes. - Attribute Value The Attribute Value includes the value of the attribute. Specific attributes will be defined in a separate memo. 5.2. Establishment of Bonding Tunnels One major goal of BANANA signaling is to enable the automatic set up of GRE tunnels which used to be set up manually. After the IP addresses of tunnel endpoints have been acquired, the local BANANA box starts the following procedure to set up the bonding tunnels. The local BANANA box sends the GRE Tunnel Setup Request message to the remote BANANA box via the endpoint F. The outer source IP address for this message is the IP address of F, while the outer destination IP address is the IP address of the branch router (if anycast is not used, the outer destination IP address would be IP address of R). The remote BANANA box with the highest priority (e.g., the one that the local BANANA box has the least-cost path to reach) in the group of remote BANANA boxes, which receives the GRE Tunnel Setup Request message, will initiate the procedure for authentication and authorization to check whether the local BANANA box is trusted by the network device attached to F. If the authentication and authorization succeed, the remote BANANA box sets the IP address of F, which is obtained from the GRE Tunnel Setup Request message (i.e., its outer source IP address), as the destination endpoint IP address of the first GRE tunnel and replies to the endpoint of the local BANANA box's first GRE tunnel with the Leymann, et al. Expires November 25, 2017 [Page 10] INTERNET-DRAFT BANANA Signaling May 25, 2017 GRE Tunnel Setup Accept message in which an IP address of R (e.g., an IP address of a Line Card in the remote BANANA box) and a Session ID randomly generated by the remote BANANA box are carried as attributes. The outer source IP address for this message is the IP address of R or the IP address of the branch router, while the outer destination IP address is the IP address of F. Otherwise, the remote BANANA box MUST send to the Local BANANA box's endpoint of the first GRE tunnel the GRE Tunnel Setup Deny message, and the local BANANA box MUST terminate the tunnel setup process once it receives the GRE Tunnel Setup Deny message. After the first GRE tunnel is successfully set up, the local BANANA box will obtain the C address (see Figure 3.1) over the tunnel from the remote BANANA box through the Dynamic Host Configuration Protocol (DHCP). After that, the local BANANA box starts to set up the second GRE tunnel. It sends a GRE Tunnel Setup Request message via S, carrying the aforementioned Session ID received from the remote BANANA box. The outer source IP address for this message is the IP address of S, while the outer destination IP address is the IP address of R. The remote BANANA box, which receives the GRE Tunnel Setup Request message, will initiate the procedure for authentication and authorization in order to check whether the local BANANA box is trusted by the network device attached to S. If the authentication and authorization succeed, the remote BANANA sets the IP address of S, which is obtained from the GRE Tunnel Setup Request message (i.e., its outer source IP address), as the destination endpoint IP address of the GRE tunnel and replies to the endpoint S with the GRE Tunnel Setup Accept message. The outer source IP address for this message is the IP address of R, while the outer destination IP address is the IP address of S. In this way, the two tunnels with the same Session ID can be used to carry traffic from the same user. That is to say, the two tunnels are "bonded" together. Otherwise, if the authentication and authorization fail, the remote BANANA box MUST send the GRE Tunnel Setup Deny message to the tunnel endpoint S. Meanwhile, it MUST send the GRE Tunnel Tear Down message to the tunnel endpoint F. The local BANANA box MUST terminate the tunnel setup process once it receives the GRE Tunnel Setup Deny message and MUST tear down the first GRE tunnel that has already been set up once it receives the GRE Tunnel Tear Down message. Leymann, et al. Expires November 25, 2017 [Page 11] INTERNET-DRAFT BANANA Signaling May 25, 2017 6. The Edge to Edge Scenario DNS server DNS server +--------------+ +--------------+ +--+ | | | | +--+ | | | +-+ | | +-+ | | | |A6|------------| | | | | |-------------|B6| | | | | |Fl--Tunnel 1--Fr| | | | | | | | +-+ |C| | | |D| +-+ | | | | | | |N| | |Sl--Tunnel 2--Sr| | |N| | | | |A4|---A1---|A|-| | | | | |-|A|--B1-----|B4| | | | |T| +-+ | | +-+ |T| | | | +--+ |DHCP +-+ | | +-+ DHCP| +--+ Host |IP pool | | IP pool| Host +--------------+ +--------------+ local remote BANANA box BANANA box Figure 6.1: Tunnel bonding for the edge to edge scenario The applicability of bonding tunnels is not limited to the single operator scenario. This section explains how bonding tunnels are adapted to the edge to edge scenario. By and large, the adaptations are implementation issues. o Addressing IP addresses of B4, B6, B1, Fr and Sr are obtained in the same way as A4, A6, A1, Fl and Sl respectively, as in the single operator scenario. C and D are the service endpoints of the bonding service at the two BANANA box respectively. IP addresses of C and D will be assigned from the locally configured IP pool via DHCP rather than be assigned remotely from the peering BANANA box. Domain names of the two BANANA boxes may be configured or obtained via [TR-069]. A query of the domain names will be resolved to the IP address of C or D by the DNS server . o Establishment of Bonding Tunnels The local BANANA box will send the GRE Tunnel Setup message to the remote BANANA box using IP address of D as the outer destination IP address and using IP address of Fl as the outer source IP address. When the remote BANANA box replies the local BANANA box with the GRE Tunnel Accept message, the outer source IP address for this message Leymann, et al. Expires November 25, 2017 [Page 12] INTERNET-DRAFT BANANA Signaling May 25, 2017 is set to the IP address of Fr or D, while the outer destination IP address is the IP address of Fl. In the GRE Tunnel Accept message, the IP address of Fr, the IP address of Sr and a Session ID randomly generated by the remote BANANA box will be carried as attributes. Tunnel 1 would be set up between Fl and Fr. For Tunnel 2, the local BANANA box will use the IP address of Sr as the outer destination IP address and IP address of Sl as the outer source IP address to send the GRE Tunnel Setup message to the remote BANANA box. In this message, the Session ID received from the remote BANANA box will be carried as an attribute. The remote BANANA box will reply the local BANANA box with a GRE Tunnel Setup Accept message. The outer source IP address for this message is the IP address of Sr while the outer destination IP address for this message is the IP address of Sl. Tunnel 2 would be set up between Sl and Sr. Since Tunnel 1 and Tunnel 2 use the same Session ID, they would be bonded together to carry traffic from the same user. For the edge to edge scenario, a BANANA box can either be "local" or "remote". The IP addresses of the service endpoint is used to break the tie. The BANANA box with the smaller IP address will be regarded as "local" while the BANANA box with the larger IP address will be regarded as "remote". 7. Security Considerations Malicious devices controlled by attackers may intercept the control messages sent on the GRE tunnels. Later on, the rogue devices may fake control messages to disrupt the GRE tunnels or attract traffic from the target local BANANA box. As a security feature, the Key field of the GRE header of the control messages is generated as a 32-bit cleartext password, except for the first GRE Setup Request message per bonding connection sent from the local BANANA box to the remote BANANA box, whose Key field is filled with all zeros. The remote BANANA box and the local BANANA validate the Key value and the outer source IP address, and they discard any packets with invalid combinations. 8. IANA Considerations IANA need not assign anything for this memo. The GRE Protocol Type, the Ethertype for the GRE Channel of the BANANA signaling, is set to 0xB7EA, which is under the control of the IEEE Registration Authority. However, IANA has updated the "IEEE 802 Numbers" IANA web page [802Type], which is of primarily historic interest. 9. References Leymann, et al. Expires November 25, 2017 [Page 13] INTERNET-DRAFT BANANA Signaling May 25, 2017 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, . [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, DOI 10.17487/RFC2890, September 2000, . [TR-069] Broadband Forum, "CPE WAN Management Protocol", Issue: 1 Amendment 5, November 2013, . [BANANA-encap] N. Leymann, C. Heidemann, et al, "BANdwidth Aggregation for interNet Access (BANANA) The Data Plane of Bonding Tunnels", draft-leymann-banana-data-encap, work in progress. 9.2. Informative References [802Type] IANA, "IEEE 802 Numbers", . Contributors Li Xue Individual Email: xueli_jas@163.com Zhongwen Jiang Huawei Technologies Email: jiangzhongwen@huawei.com Leymann, et al. Expires November 25, 2017 [Page 14] INTERNET-DRAFT BANANA Signaling May 25, 2017 Authors' Addresses Nicolai Leymann Deutsche Telekom AG Winterfeldtstrasse 21-27 Berlin 10781 Germany Phone: +49-170-2275345 Email: n.leymann@telekom.de Cornelius Heidemann Deutsche Telekom AG Heinrich-Hertz-Strasse 3-7 Darmstadt 64295 Germany Phone: +49-6151-5812721 Email: heidemannc@telekom.de Mingui Zhang Huawei Technologies No. 156 Beiqing Rd. Haidian District Beijing 100095 China Email: zhangmingui@huawei.com Behcet Sarikaya Huawei USA 5340 Legacy Dr. Building 3 Plano, TX 75024 United States of America Email: sarikaya@ieee.org Margaret Cullen Painless Security 14 Summer St. Suite 202 Malden, MA 02148 United States of America Email: margaret@painless-security.com Leymann, et al. Expires November 25, 2017 [Page 15]