idnits 2.17.00 (12 Aug 2021) /tmp/idnits63782/draft-heileyli-gre-notifications-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 228 has weird spacing: '... Mobile netw...' -- The document date (October 21, 2013) is 3127 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2697 ** Downref: Normative reference to an Informational RFC: RFC 2698 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Interdomain Routing Working Group N. Leymann, Ed. 3 Internet-Draft C. Heidemann 4 Intended status: Standards Track Deutsche Telekom AG 5 Expires: April 24, 2014 X. Li 6 Huawei 7 October 21, 2013 9 GRE Notifications 10 draft-heileyli-gre-notifications-00 12 Abstract 14 GRE (Generic Routing Encapsulation) specifies a protocol for the 15 encapsulation of an arbitrary protocol over another arbitrary network 16 layer protocol. 18 This document describes extensions to manage multiple GRE tunnels 19 over multiple access lines to one home network with the purpose to 20 present a novel architecture using Hybrid Access (HA) networks. HA 21 is designed to bundle multiple access technologies, e.g. fixed access 22 and wireless access to one Internet connection. This enables higher 23 bandwidth for end customers. The document describes the Hybrid 24 Access network architecture and th extensions for GRE which are 25 necessary to implement the HA architecture. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 24, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 70 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Hybrid Access Network Architecture . . . . . . . . . . . . . 5 72 5. Solution Approach Overview . . . . . . . . . . . . . . . . . 7 73 5.1. Dynamic GRE Definition . . . . . . . . . . . . . . . . . 7 74 5.2. Bonding Tunnel Establishement Overview . . . . . . . . . 8 75 6. Dynamic GRE State Machine Definition . . . . . . . . . . . . 10 76 7. Dynamic Packet Format . . . . . . . . . . . . . . . . . . . . 11 77 7.1. Dynamic GRE Control Messages . . . . . . . . . . . . . . 11 78 7.2. Dynamic GRE Protocol Messages Attributes . . . . . . . . 12 79 8. Overflow Bonding Operations . . . . . . . . . . . . . . . . . 14 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 81 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 83 12. Normative References . . . . . . . . . . . . . . . . . . . . 15 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 86 1. Introduction 88 This document specifies a new GRE extension which allows the 89 operators to have home networks that consist of at least two IP 90 access lines to the same location from one network gateway. GRE 91 tunnels are used to combine the multiple access lines together to one 92 Internet connection. The combination from e.g. a wireless access 93 (LTE) and a fixed line (DSL) access enables new use cases:. 95 1. Bandwidth on demand, if fixed line is full, bandwidth of mobile 96 access is added on demand 98 2. Seamless handover, if one access lines fails the service can 99 still be provided without interruption 101 3. Application dependent transport of different combined or non- 102 combined access lines to one home network location 104 This extension contains signaling information to manage those 105 multiple GRE connections over the multiple access lines. The lines 106 can have different weight and qualities and have to be merged to one 107 authorized connection. Therefore a signaling is needed for the 108 following cases: 110 1. Signaling of the IP addresses of the access lines and IP 111 addressed of the combination GRE tunnels 113 2. Signaling of the weight of one access line, a cheaper access line 114 should be used 116 3. Signaling of keep alive to decide which GRE tunnels are active 117 and can be used 119 4. Signaling of bypass traffic amount which should be bypassed from 120 the tunnels 122 5. Signalling of deny and allowed messages 124 2. Use Cases 126 Recently, the existing network status can bringing changes to the 127 operator's network: Higher bandwidth requirement and current limited 128 usage of existing networks(e.g.wireless network: LTE, etc). There is 129 a strong interest to integrate the existing network resource as a 130 single Internet connection for end customers. The resulting network 131 is called a Hybrid Access (HA) network. The HA network can be 132 controlled by the user's Customer Premise Equipment (CPE). The 133 connectivity in HA is being implemented by using a tunnel mechanism 134 on top of the physical infrastructure. 136 This document described the HA architecture by illustrating DSL and 137 LTE bundled. Nevertheless the solution is not limited to those 138 technologies and can be easily applied to other scenarios. This 139 document describes the base HA network architecture, while solution 140 approach with extensions of GRE protocol [RFC2890] will realize HA 141 network architecture. 143 With HA many deficiencies in the current operator's network, 144 following use cases are enabled. 146 1. Bandwidth On Demand 148 Typically end customers are only connected using a single link (e.g. 149 fixed or wireless) to the network of a service provider. If the 150 required bandwidth exceeds the bandwidth provided by the link usually 151 the link needs to be upgraded. However, using the current network 152 deployment model such an upgrade is not always economically feasible. 153 A different approach is needed. 155 In this model end customer are connected over one standard access 156 line (e.g.fixed line: DSL, Cable, ...) primarily to the operator's 157 service. In addition there are one or more another connections over 158 the different access technologies, (e.g. wireless line: LTE). If the 159 traffic exceeds the bandwidth of the primary access line the bundled 160 connections can provide a higher bandwidth to the end customer. 162 2. Seamless Handover 164 In HA network, the customer has a CPE connection through the access 165 network (e.g.fixed line: DSL, Cable, ...). The CPE also provides a 166 back-up WAN connection through another network (e.g. wireless line: 167 LTE), when the fixed line is unavailable. 169 The customer is using Internet service via fixed WAN connection. 170 When the fixed connection gets disconnected unexpectedly, the ongoing 171 service is automatically switched to the backup connection. The 172 Internet service is not interrupted by this event and continues 173 seamlessly by end-user. 175 3. Conventions and Terminology 177 3.1. Terminology 179 Bonding Tunnel: The bundling tunnel of both fixed access tunnel and 180 wireless access tunnel. The bonding tunnel in HA is the 181 connection on top of the physical infrastructure, terminated 182 between CPE and HAAP. 184 Tunnel Transit IP: The outer IP of a GRE encapsulation. 186 DSL Tunnel: The GRE tunnel between CPE DSL WAN and HAAP. The tunnel 187 transit IP is IP address of CPE DSL WAN interface and HAAP 188 address. It is one subset tunnel of bonding tunnel. 190 Dynamic GRE: The dynamic stateful GRE tunnel. 192 Customer Premise Equipment (CPE): A device that connects multiple 193 terminals to provide connectivity to the service providers 194 network. 196 Hybrid Access (HA): Hybrid Access (HA) is the bundling of two or 197 more access line over different technologies (e.g. DSL and LTE) to 198 one Internet connection for end customers. 200 Hybrid Access Aggregation Point (HAAP): The HAAP which acts as a 201 service termination and a service creation implements bonding 202 mechanism and sets up a high speed Internet dual stack IP 203 connection with CPE on top of two or more different access 204 technologies. 206 HA IP: The inner IP of a GRE encapsulation. This IP is assigned by 207 HAAP to CPE; this is the IP for the Internet communication. 208 Sometimes it is called tunnel IP in this document. 210 LTE Tunnel: The GRE tunnel between CPE LTE WAN and HAAP. The tunnel 211 transit IP is IP address of CPE LTE WAN interface and HAAP 212 address. It is one subset tunnel of bonding tunnel. 214 4. Hybrid Access Network Architecture 216 The basic idea of Hybrid Access is the bundling of the DSL and LTE 217 access technologies. Figure 1 illustrates one example of Hybrid 218 Access network. 220 |==============================================| 221 | <........e.g. LTE Tunnel ..................> | 222 <--->| <........e.g. DSL Tunnel ..................> |<---> 223 |==============================================| ----- 224 +--+---+ Bonding Tunnel +----+----+ / \ 225 | | | | | Internet| 226 | CPE | | HAAP +---+ | 227 +--++--+ +---+-+---+ \ / 228 || Mobile network | | ----- 229 || *......................... * | | 230 || < +------+ +------+ > | | 231 |+----------+ +-------+ +-----------+ | 232 | < |eNodeB| | EPC | > | 233 | < +------+ +------+ > | 234 | *..........................* | 235 | | 236 | *......................... * | 237 | ( +------+ +------+ ) | 238 +-----------+ +-------+ +-------------+ 239 ( | AN | | SN | ) 240 ( +------+ +------+ ) 241 *..........................* 242 Fixed Network 243 Legend: 244 AN Access Node 245 CPE Customer Premise Equipment 246 SN Service Node 247 EPC Evolved Packet Core 248 HAAP Hybrid Access Aggregation Point 250 Figure 1: Hybrid Access Network Architecture 252 In the fixed network, users are served fixed services by the Access 253 Node (AN) and Service Node (e.g. Broadband Network Gateway (BNG)). 254 In the wireless network, cellular sites are connected to the mobile 255 core network using mobile backhaul network and EPC core network. The 256 new approach of Hybrid should take into consideration the fact that 257 operators introduces additional network bandwidth resource with 258 limited usage to users. 260 In the HA architecture, on the client site, CPE is used to implement 261 the bonding mechanism for customers. On the network side, a device 262 named as Hybrid Access Aggregation Point (HAAP) MUST be deployed. 263 The HAAP which acts as a service termination and a service creation 264 implements bonding mechanism and sets up a higher speed Internet dual 265 stack IP connection with the CPE on top of both access technologies 266 a.k.a., DSL and LTE. The HA connection between the end user's CPE 267 and the HAAP could be done by using the tunnel mechanism on top of 268 the physical infrastructure. This document describes the extensions 269 for dynamic GRE which are necessary. 271 The bonding tunnel between CPE and HAAP carries best effort traffic 272 going to and coming from the public Internet. Particularly, based on 273 the operator's requirement, it is possible that not all traffic from 274 the home network is routed into the bonding tunnel in order to ensure 275 that existing services are not influenced by using HA. Certain 276 traffic such as VoIP, IPTV traffic depending on its destination or 277 QoS markings, needs to be routed via the fixed line interface or via 278 the wireless interface instead to be routed into the bonding tunnel 279 between CPE and HAAP. The CPE should implement an mechanism which 280 can be used to specify exceptions (traffic which should not be routed 281 into the tunnel). This mechanisms is out of scope of this document. 283 5. Solution Approach Overview 285 The bonding tunnel behavior is accomplished by implementing dynamic 286 subset tunnels setup and bonding them together during the procedure. 287 This section identifies the HA solution approaches that operators can 288 leverage for deploying HA technologies, which is dynamic Generic 289 Routing Encapsulation (GRE). 291 5.1. Dynamic GRE Definition 293 The dynamic GRE protocol is specified for encapsulation of the user 294 traffic over multiple arbitrary network layer via bundling mechanism 295 on CPE and HAAP. This section describes dynamic GRE protocol. 297 The dynamic GRE protocol transport layer carries GRE encapsulated 298 Control messages, and GRE encapsulated Data messages. GRE Data 299 messages encapsulate forwarded user frames. GRE Control messages are 300 management messages exchanged between a CPE and a HAAP in HA 301 architecture. The format of GRE protocol Control are defined in 302 section 7. 304 The dynamic GRE protocol begins with a base access phase. CPE gets 305 DSL WAN interface IP address through PPPoE from service node (e.g., 306 BNG) or DHCP and LTE WAN interface IP address through Packet Data 307 Protocol (PDP)[TS23.401] from PGW. Additionally, CPE obtains HAAP 308 address for tunnel establishment. From the base access phase, a CPE 309 discoveries the HAAP with which to establish the tunnels for HA. 311 Once the base access have be completed, GRE Request is initiated by 312 CPE in order to begin bonding tunnels setup phase between CPE and 313 HAAP. CPE setups the authorized LTE GRE tunnel before DSL GRE tunnel 314 by sending GRE Request control messages via LTE WAN interface to 315 HAAP. After, CPE obtains HA IP address from HAAP through DHCP over 316 LTE GRE tunnel. Subsequently, authorized DSL GRE tunnel is 317 established. During these exchanges, the CPE may receive some 318 information in order to enable both tunnel bundled. GRE Accept/Deny 319 identifies that GRE tunnel setup request is accepted/rejected. 321 When the CPE and HAAP have completed the bonding tunnels setup 322 exchange, the customers have the single service connection through 323 both access technologies infrastructure. Particularly,the specific 324 traffic will send through the bonding tunnels and thus encapsulated 325 by GRE. As long as the primary connection (e.g., DSL) is sufficient, 326 traffic goes through the DSL GRE tunnel only. If traffic exceeds the 327 bandwidth, traffic overflows to the LTE GRE tunnel. 329 The dynamic GRE also provides commands exchange between CPE and HAAP 330 for HA management. These may be included in GRE Notify message for 331 tunnel status/information changing between CPE and HAAP. These may 332 include the bypass traffic amount which should be bypassed from the 333 bonding tunnels. 335 The dynamic GRE protocol provides for a keep-alive feature that 336 preserves the communication channel between the CPE and HAAP. If the 337 tunnels fail to appear alive, the CPE will try to re-establish it. 338 For example, if the DSL tunnel cannot be re-established, HA traffic 339 will still run through the LTE tunnel only. If the LTE tunnel cannot 340 be re-established, new Internet sessions will be established over 341 native DSL. The DSL tunnel will be finally torn down after a period 342 without service interruption. 344 For maintenance reasons, the GRE Tear Down message also can be used 345 by CPE and HAAP to complete the HA architecture in out of service 346 scenario. 348 5.2. Bonding Tunnel Establishement Overview 350 This section describes the bonding tunnel establishment process 351 message exchanges between CPE and HAAP. The annotated ladder diagram 352 shows the CPE on the left, the HAAP on the right. The dynamic GRE 353 state mechanism is defined in detail in Section 6. Note that in the 354 Authentication step, the authentication required certain messages are 355 aggregated into a single step, which is denoted via an asterisk line 356 in Figure 2 358 ========== :::::::::: ========== 359 CPE SN/PGW HAAP 360 ========== :::::::::: ========== 362 [...CPE gets DSL WAN connection through PPPoE/DHCP ....] 363 [...CPE gets LTE WAN connection through PDP from PGW...] 364 [........ CPE gets HAAP address via DNS .............] 366 [.......... begin bonding tunnel setup ............... 367 (........ begin lte gre tunnel setup .............) 369 -------- LTE GRE Setup Request --------------> 371 **** Authentication and Authorization Passed ***** 373 <-------- LTE GRE Setup Accept(session ID) ------ 375 (......... lte gre tunnel is setup now ............) 377 ---- Request HA IP Address (DHCP over LTE GRE) ---> 378 <--IP Address Assigned to CPE(DHCP over LTE GRE)---- 380 (........ begin dsl gre tunnel setup .............) 382 -------- DSL GRE Setup Request (session ID) ----> 384 **** Authentication and Authorization Passed ***** 386 <-------- DSL GRE Setup Accept ---------------- 388 (........ dsl gre tunnel is setup now ............) 390 [.......... bonding tunnel is setup now...............] 392 Figure 2: GRE Tunnel Establishment 394 At the end of the illustrated GRE control messages exchange, the 395 bonding tunnel between CPE and HAAP is setup completely by binding 396 LTE Tunnel and DSL Tunnel with same session ID, defined in 397 Section 7.2. 399 After, the CPE and HAAP are securely exchanging GRE Control messages 400 for tunnel keepalive (GRE Hello) and management (GRE Notify). 402 The GRE Notify message is used to inform status/information changing 403 information between CPE and HAAP. A notify acknowledgement (ACK) and 404 retransmission mechanism can be used to provide certain level 405 reliable transport capability. When receiving end receives a notify 406 packet, it will send back a GRE notify packet without any 407 attributions appended to the sending end immediately as 408 acknowledgement for the notify packet. When sending end doesn't 409 receive the notify ACK message in after a specific seconds, sending 410 end treats it as lost of notify message and will retransmit the 411 notify message. 413 When sending end not receiving the notify ACK for a certain notify 414 message for continually specific times, sending end treats it as 415 sending failure and tunnel failure also, sending end will tear down 416 the GRE tunnel which sent the notify message. If the CPE is the 417 sending end, the CPE will tear down the tunnel over which the notify 418 packet was send, and try to re-establish the tunnel. If HAAP is the 419 sending end, the HAAP will tear down the corresponding GRE tunnel and 420 wait for CPE to reestablish it. 422 This illustration is provided to clarify the protocol operation, and 423 does not include any possible error conditions and all the control 424 packets. Section 6 provides a detailed description of the 425 corresponding state machine. 427 6. Dynamic GRE State Machine Definition 429 The following state diagram (Figure 3) represents the life cycle of 430 HA bonding tunnel. 432 +------------TUNNEL UP--------------+ 433 | | 434 /-+-\ /-V-\ 435 + LTE UP--> +-DSL UP+ +-------> +-------+ 436 | | 6 | | DSL DOWN| 7 |LTE DOWN 437 | \---/ | TUNNEL | \-+-/ | 438 /-+-\ /-V-\ UP /-+-\ | /-V-\ 439 | | | +-------> <-DSL UP+ | | 440 | 1 | | 3 | | 4 <-LTE UP+ | 8 | 441 \^+-/ \-^-/ \-+-/ | \-^+/ 442 || | | | || 443 || | | | DSL DOWN| 444 || /---\ | LTE DOWN /-+-\ || 445 |+-DSL UP--> +-LTE UP+ +-------> +-------+| 446 | | 2 | | 5 | | 447 | \-^-/ \-+-/ | 448 | | TUNNEL DOWN IDLE TIMEOUT | | 449 | +-----------------------------------+ | 450 +-------------------------------------------------------------+ 451 TUNNEL DOWN 453 Figure 3: GRE State Machine 455 The various states are described as below: 457 State No. DSL Tunnel LTE Tunnel Bonding Tunnel 458 ========= =========== =========== =============== 460 1 Down Down Down 461 2 Up Down Down 462 3 Up Up Down 463 4 Up Up Up 464 5 Up Down Up 465 6 Down Up Down 466 7 Down Up Up 467 8 Down Down Up 469 Tunnel / GRE States 471 7. Dynamic Packet Format 473 This section describes GRE encapsulated control messages definitions 474 and attributes which can be optionally carried in the GRE control 475 messages. 477 7.1. Dynamic GRE Control Messages 479 The GRE control messages are defined according to [RFC2890]. The 480 proposed GRE header of the control messages has the following format 481 (see Figure 4): 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 |C| |K|S| Reserved0 | Ver | Protocol Type | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Key | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 |MsgType|T| Res |Attribute Type | Attribute Length | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Attribute Value | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 Figure 4: GRE Header Format 497 Protocol Type (2 octets) 499 The Protocol Type field identifies the dynamic GRE protocol. The 500 value is TBD. 502 Message Type (MesType) (4 bits) 504 The Message Type field identifies the dynamic GRE protocol control 505 messages in the HA network. The value is TBD. The existing control 506 message types are listed below. Additional values may be defined in 507 the future. 509 Control Message Family Type 510 ========================= ============ 512 GRE Setup Request 1 513 GRE Setup Accept 2 514 GRE Setup Deny 3 515 GRE Hello 4 516 GRE Tear Down 5 517 GRE Notify 6 518 Reserved 0,7-15 519 Figure 5: GRE Control Messages 521 Tunnel Type (T) (1 bit) 523 It indicates this control message for the type of the subset tunnel 524 in HA. For example, if the Tunnel Type (T) bit is set to 1, then 525 this control message is for the DSL tunnel shown in Figure 5. 526 Otherwise it indicates that this is for the LTE tunnel shown in 527 Figure 5. 529 Attribute Type (1 octet) 531 The Attribute Type indicates the type of the appended attribution in 532 the control message. The attribute value pair is defined in 533 Section 7.2. 535 Attribute Length (2 octets) 537 The Attribute Length field indicates the length of the attribute by 538 byte. 540 Attribute Value (variable) 542 The Attribute Value field includes the value of the attribute. 544 7.2. Dynamic GRE Protocol Messages Attributes 546 This section defines the attributions that are included in dynamic 547 GRE protocol control messages. Attributions are used to carry 548 information needed during bonding tunnel setup and management 549 procedure. Every attribution is identified by the Type, Length, 550 Value field. All of the message attributions in this document use 551 the same format, shown as below in Figure 6. 553 0 1 2 3 554 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 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 |Attribute Type | Attribute Length |Attribute Value| 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Attribute Value...... | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 Figure 6: GRE Message Attributes 563 The 8-bits Type field identifies the type of the appended attribution 564 carried in Attribute Value field in the control messages header. The 565 type field values are allocated right now listed in this section as 566 follows: 568 o Session ID 570 This is 32 bits value is generated by HAAP, and unified within a 571 HAAP, to identify a certain subscriber. This value is using to 572 binding the DSL tunnel and LTE tunnel together for individual HA 573 user. HAAP generates a session ID for a HA user's and sends this 574 value to CPE via LTE GRE setup accept, then CPE carries this value in 575 the DSL GRE setup request, defined in section 4.2. With this 576 information, HAAP binds the DSL tunnel and LTE tunnel together, then 577 bonding GRE tunnel is achieved accordingly. When LTE recovery from 578 failure with DSL tunnel exists, the re-establish LTE tunnel request 579 need carry the Session ID attribute. 581 Type: 4 for Session ID 583 Length: 4 Octets 585 Value: 32 bits value generated by HAAP. 587 o Bypass Traffic Rate 589 This attribute is used to notify HAAP of the downstream bypass 590 traffic on CPE via DSL Notify control message from CPE. HAAP will 591 calculate the available DSL bandwidth for DSL GRE tunnel based on 592 this information. CPE and HAAP can decide the bypass traffic amount 593 which should be bypassed from the combination tunnels. The unit of 594 this value is kbps. 596 Type: 6 for Bypass traffic rate 598 Length: 4 Octets 600 Value: Downstream bypass traffic on CPE. 602 o Hello Interval 604 This is the configuration which is assigned to the CPE by the HAAP. 605 Configure the Hello signaling checking period on CPE from HAAP. The 606 unit of this value is second. This attribution is carried in GRE 607 Setup Accept control message for LTE tunnel. 609 Type: 14 for Hello Interval 611 Length: 4 Octets 613 Value: Hello Interval 615 8. Overflow Bonding Operations 617 In HA network, the user traffic can be transferred to wireless access 618 (Overflow tunnel) when the fixed line (Primary tunnel) bandwidth is 619 not any more sufficient. 621 There are two types of overflow bonding mechanisms, packet-based 622 balancing and stream-based balancing. Balancing per stream can 623 require the DSL bandwidth threshold configuration. The steam only 624 runs over the DSL or LTE link. Balancing of per packet will use DSL 625 bandwidth as soon as DSL bandwidth is not full. It is possible that 626 the same stream can run the different DSL and LTE link at the same 627 time. In HA network, packet-based balancing is proposed for 628 efficiency. 630 The packet-based overflow balancing is based on the Single Rate Three 631 Color Marker (srTCM) and Two Rate Three Color Marker (trTCM) which is 632 defined in[RFC2697] and [RFC2698].The packet is marked if the packet 633 is overflowed or not. The CIR (Committed Information Rate) is equal 634 to the DSL bandwidth minus several layers' overhead. The CBS 635 (Committed Burst Size) provides the burst capability which can help 636 TCP achieve the committed bandwidth. This mechanism is used on both 637 HAAP for downstream overflow bonding and CPE for upstream overflow 638 bonding. 640 Then the colored based policy routing is executed for packet-based 641 balancing, user's packet will be routed into the corresponding tunnel 642 based on color. For example,Yellow color packet will be routed to 643 LTE GRE tunnel; green color packet will be routed into DSL GRE 644 tunnel. At this stage, the GRE IP header will be added. 646 Additionally, during the packet-based balancing, reorder mechanism 647 are need for both HA downstream and upstream. On the downstream, the 648 packets encapsulated in GRE will come from DSL GRE tunnel and/or LTE 649 GRE tunnel. The packets will be sent to a buffer for reordering. If 650 the GRE sequence number is not continuous, the packets will be 651 buffered until the missing sequence packet has arrived or the 652 buffering time has expired. After reordering, the GRE header will be 653 removed and the packet will be sent to the ordinary CPE processing. 654 Upstream direction reordering is performed on HAAP using the same 655 mechanism as downstream. 657 In order to ensure that existing services are not influenced by using 658 HA, it is possible that certain traffic does not be routed through 659 the tunnel, but directly over the corresponding interfaces. This is 660 necessary in case the tunnel and the HAAP are not supporting QoS 661 (e.g. for IPTV or VoIP services) and Multicast (for IPTV). Some 662 customers delay-sensitive traffic (like Internet gaming) need to be 663 sent through the fixed line interface to ensure quality of experience 664 depending on customer requirements. 666 This bypass behavior is accomplished by implementing a routing table 667 which routes traffic which needs to bypass the tunnel through its 668 relevant interfaces. For example, IPTV related traffic might be 669 routed over the fixed line interface to ensure the use of QoS. 671 9. IANA Considerations 673 IANA is requested to allocate one code TBD for the dynamic GRE 674 protocol. 676 10. Security Considerations 678 In the whole processing of HA, security of control messages MUST be 679 guaranteed. The CPE discovers the HAAP by resolving the HAAP address 680 over DNS. This protects the CPE against connections to foreign HAAP, 681 if the DNS service and the domain name in the CPE isn't corrupted. 683 The CPE should be prevented against receiving GRE notifications 684 without a valid session In the whole processing of end to end HAAP 685 session establishing and GRE notification signaling, the source IP 686 address for session establishment from CPE MUST be strictly verified, 687 including IP address authentication and identification at the HAAP 688 side. Any authentication mechanism with credential or checking the 689 IP address is feasible. 691 GRE notification key poisoning Every new session at the HAAP 692 generates a magic number, which is encapsulated in the key field of 693 the GRE header and will be carried in the signalling messages and 694 data traffic for verification by comparing the Magic Number in the 695 message and the Magic Number in the local session table. Traffic 696 without a valid Magic Number and outer IP address will be discarded 697 on the HAAP. Magic number is used for both control message and data 698 message security. 700 For data traffic security, it is also proposed to use IP address 701 validation to protect against IP Spoofing attacks. 703 11. Acknowledgements 705 Many thanks to Dennis Kusidlo. 707 12. Normative References 709 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 710 Requirement Levels", BCP 14, RFC 2119, March 1997. 712 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 713 Marker", RFC 2697, September 1999. 715 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 716 Marker", RFC 2698, September 1999. 718 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 719 RFC 2890, September 2000. 721 [TS23.401] 722 , "3GPP TS23.401, General Packet Radio Service (GPRS) 723 enhancements for Evolved Universal Terrestrial Radio 724 Access Network (E-UTRAN) access", September 2013. 726 Authors' Addresses 728 Nicolai Leymann (editor) 729 Deutsche Telekom AG 730 Winterfeldtstrasse 21-27 731 Berlin 10781 732 Germany 734 Phone: +49-170-2275345 735 Email: n.leymann@telekom.de 737 Cornelius Heidemann 738 Deutsche Telekom AG 739 Heinrich-Hertz-Strasse 3-7 740 Darmstadt 64295 741 Germany 743 Phone: +4961515812721 744 Email: heidemannc@telekom.de 746 Xue Li 747 Huawei 748 NO.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan 749 Beijing, HaiDian District 100095 750 China 752 Email: xueli@huawei.com