idnits 2.17.1 draft-lhwxz-gre-notifications-hybrid-access-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Filter List Package is the collection of the services list which MUST not be routed through HYA, but directly over the specific interface mentioned in Section 5.3. The filter service list is configured on CPE by HAAP. This attribute is the collection of filter list TLVs, each TLV carries one kinds of filter service list. -- The document date (January 14, 2015) is 3361 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) == Unused Reference: 'RFC2697' is defined on line 1552, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-lhwxz-hybrid-access-network-architecture-00 ** Downref: Normative reference to an Informational draft: draft-lhwxz-hybrid-access-network-architecture (ref. 'I-D.lhwxz-hybrid-access-network-architecture') ** Downref: Normative reference to an Informational RFC: RFC 2697 ** Downref: Normative reference to an Informational RFC: RFC 2698 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Interdomain Routing Working Group N. Leymann 3 Internet-Draft C. Heidemann 4 Intended status: Standards Track Deutsche Telekom AG 5 Expires: July 18, 2015 M. Wesserman 6 Painless Security 7 L. Xue 8 M. Zhang 9 Huawei 10 January 14, 2015 12 GRE Notifications for Hybrid Access 13 draft-lhwxz-gre-notifications-hybrid-access-01 15 Abstract 17 This document specifies a set of GRE (Generic Routing Encapsulation) 18 extensions which enable operators to construct residential networks 19 that are able to access the provider service through more than one 20 hybrid access networks simultaneously in order to satisfy the higher 21 bandwidth requirements. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 11, 2014. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. GRE Solution Overview . . . . . . . . . . . . . . . . . . . . 4 66 4. IP Address Assignment . . . . . . . . . . . . . . . . . . . . 7 67 4.1. IPv4 Address Assignment . . . . . . . . . . . . . . . . . 7 68 4.2. IPv6 Address Assignment . . . . . . . . . . . . . . . . . 7 69 5. GRE Solution Function . . . . . . . . . . . . . . . . . . . . 9 70 5.1. GRE Tunnels Setup and Management . . . . . . . . . . . . 9 71 5.2. Packet-Based Traffic Overflow . . . . . . . . . . . . . . 12 72 5.3. Backward Compatibility . . . . . . . . . . . . . . . . . 13 73 5.4. Bypassing Traffic Statistic . . . . . . . . . . . . . . . 14 74 5.5. LTE and DSL Path Difference Consideration . . . . . . . . 15 75 6. GRE Control Message Definition . . . . . . . . . . . . . . . 15 76 6.1. GRE Setup Request Message . . . . . . . . . . . . . . . . 17 77 6.2. GRE Setup Accept Message . . . . . . . . . . . . . . . . 17 78 6.3. GRE Setup Deny Message . . . . . . . . . . . . . . . . . 18 79 6.4. GRE Hello Message . . . . . . . . . . . . . . . . . . . . 18 80 6.5. GRE Tear Down Message . . . . . . . . . . . . . . . . . . 18 81 6.6. GRE Notify Message . . . . . . . . . . . . . . . . . . . 19 82 7. GRE Control Message Attribute Definitions . . . . . . . . . . 20 83 7.1. Client Identification Name (CIN) . . . . . . . . . . . . 21 84 7.2. Session ID . . . . . . . . . . . . . . . . . . . . . . . 21 85 7.3. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 22 86 7.4. Bypass Traffic Rate . . . . . . . . . . . . . . . . . . . 22 87 7.5. Filter List Package . . . . . . . . . . . . . . . . . . . 23 88 7.6. RTT Difference Threshold . . . . . . . . . . . . . . . . 24 89 7.7. Bypass Bandwidth Check Interval . . . . . . . . . . . . . 25 90 7.8. Switching to DSL Tunnel . . . . . . . . . . . . . . . . . 26 91 7.9. Overflowing to LTE Tunnel . . . . . . . . . . . . . . . . 26 92 7.10. Hello Interval . . . . . . . . . . . . . . . . . . . . . 26 93 7.11. Hello Retry Times . . . . . . . . . . . . . . . . . . . . 27 94 7.12. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 27 95 7.13. Error Code . . . . . . . . . . . . . . . . . . . . . . . 28 96 7.14. DSL Link Failure . . . . . . . . . . . . . . . . . . . . 28 97 7.15. LTE Link Failure . . . . . . . . . . . . . . . . . . . . 28 98 7.16. IPv6 Prefix Assigned to Terminal Host . . . . . . . . . . 29 99 7.17. Subscribed DSL Upstream BW . . . . . . . . . . . . . . . 30 100 7.18. Subscribed DSL Downstream BW . . . . . . . . . . . . . . 30 101 7.19. Delay Difference Threshold Violation . . . . . . . . . . 31 102 7.20. Delay Difference Threshold Compliance . . . . . . . . . . 31 103 7.21. Filter list ACK . . . . . . . . . . . . . . . . . . . . . 32 104 7.22. End AVP . . . . . . . . . . . . . . . . . . . . . . . . . 33 105 8. GRE Tunnels State Machine . . . . . . . . . . . . . . . . . . 33 106 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 107 10. Security Considerations . . . . . . . . . . . . . . . . . . . 34 108 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 109 12. Normative References . . . . . . . . . . . . . . . . . . . . 35 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 112 1. Introduction 114 In order to provide higher bandwidth for residential subscribers, 115 operators prefer to bond the LTE network with DSL network to transfer 116 the subscriber traffics. Especially, in some certain places (e.g. 117 the old cities downtown), the DSL network is already overloading, 118 even it is extremely difficult to be updated and rebuilt because of 119 construction . To satisfy this requirement, HYbrid Access(HYA) 120 architecture is designed in 121 [I-D.lhwxz-hybrid-access-network-architecture]. A solution is 122 required to fill the gaps for operators deploying HYA. 124 This document proposes a packet-based HYA solution, which achieves 125 bonding the hybrid access networks via extended Generic Routing 126 Encapsulation (GRE)[RFC2890] protocol. This document presents the 127 GRE protocol extensions required for HYA, specifically, those for 128 signalling to setup, bond and management these GRE tunnels, 129 signalling for reorder and reassemble customer traffics. 131 This remainder of this document is organized as follows. Section 2 132 lists the key terms used in this document. Section 3 outlines the 133 overview of GRE solutions. In section 4, IP address assignment in 134 HYA is described. Section 5 discusses the GRE solution functions. 135 The definition of GRE control messages needed in HYA are listed in 136 Section 6. The attributions used in GRE solutions are listed in 137 Section 7. In Section 8, GRE Tunnels State MachineSection 8 is 138 discussed. 140 2. Terminology 142 Customer Premise Equipment (CPE): A device that connects multiple 143 hosts to provide connectivity to the service providers network. 145 DSL GRE Tunnel: The GRE tunnel between CPE DSL WAN and HAAP. The 146 DSL GRE tunnel termination IP addresses are IP address of CPE DSL 147 WAN interface and HAAP address. 149 HYbrid Access (HYA): HYbrid Access (HYA) is the bundling of two or 150 more access lines over different technologies (e.g. DSL and LTE) 151 to one Internet connection for end customers. 153 Hybrid Access Aggregation Point (HAAP): The HAAP which acts as a 154 service termination and a service creation implements bonding 155 mechanism and sets up a high speed Internet dual stack IP 156 connection with CPE on top of two or more hybrid access 157 technologies. The packet reorder, reassemble functions in packet- 158 based solutions should be supported on HAAP. 160 HA Tunnel: HA Tunnel represents LTE GRE tunnel and DSL GRE tunnel 161 defined between CPE and HAAP. 163 LTE GRE Tunnel: The GRE tunnel between CPE LTE WAN and HAAP. The 164 LTE GRE tunnel termination IP addresses are IP address of CPE LTE 165 WAN interface and HAAP address. 167 3. GRE Solution Overview 169 The GRE solution is proposed as a candidate solution for HYA based on 170 per-packet traffic distribution mechanism. Only a dedicated GRE 171 tunnel is setup over either hybrid access network between CPE and 172 Hybrid Access Aggregation Point (HAAP), DSL GRE tunnel and LTE GRE 173 tunnelFigure 1. Bonding these GRE tunnels is preformed on CPE and 174 HAAP. In addition, the types of packet distribution rules over 175 hybrid accesses are deployed on both CPE and HAAP according to kinds 176 of criteria (e.g., DSL load, failures, service list, etc). 178 To achieve these performances, the possible communications between 179 CPE and HAAP are needed to achieve GRE tunnel setup, bonding and 180 management, while to deploy and control the consistent traffic 181 distribution for efficiency use of network resources. In addition, 182 packet reorder, reassemble and fragmentation issues should be settled 183 based on this 184 communication[I-D.lhwxz-hybrid-access-network-architecture]. 186 |============================================== 187 | <............ LTE path .................> | 188 <--->| <............ DSL path .................> |<---> 189 |============================================== ---- 190 +--+---+ +---+---+ / \ 191 | | | | |Internet| 192 | CPE | | HAAP +--+ | 193 +-+--+-+ +---+---+ \ / 194 D E LTE Network H ---- 195 | | *......................... * | | 196 | | < +------+ +------+ > | | 197 | +--------+ +-------+ +------------+ | 198 | < |eNodeB| | EPC | > | | 199 | < +------+ +------+ > | | 200 | *..........................* | | 201 | *......................... * | | 202 | ( +------+ +------+ ) | | 203 +-----------+ +-------+ +------------+-----------+ 204 ( | AN | | SN | ) 205 ( +------+ +------+ ) 206 *..........................* 207 DSL Network 208 Legend: 209 AN Access Node 210 SN Service Node 211 EPC Evolved Packet Core 213 Figure 1: Hybrid Access Network Architecture 215 Once LTE and DSL GRE tunnels establishment and bonding procedure are 216 completed, customer traffics can be distributed into LTE and/or DSL 217 GRE tunnel based on traffic distribution rules on CPE and HAAP. The 218 traffic encapsulation is shown in Figure 2. 220 +--------+ +--------------+ +--------+ 221 | CPE | | LTE Network | | HAAP | 222 | +-+****************************************** | 223 | | | +-| | | | | | | 224 | | | |E+....lte gre tunnel....... | | | | 225 | | | +-+ +--------------+ ........ | | 226 | |C| | +.-.-.-.H| | 227 | | | +-+ +--------------+ | | | | | 228 | | | |D+.-.-dsl gre tunnel.-.-.-. | | | | 229 | | | +-+ | | | | | | 230 | +-+****************************************** | 231 | | | DSL Network | | | 232 +--------+ +--------------+ +--------+ 234 ------------> Upstream Traffic 236 +---------+ +----------+ +----------+ +---------+ 237 | Payload | | Payload | | Payload | | Payload | 238 +---------+ +----------+ +----------+ +---------+ 239 |Src:CPE C| |Src:CPE C | |Src:CPE C | |Src:CPE C| 240 +---------+ +----------+ +----------+ +---------+ 241 |Dst:Inter| |Dst:Inter | |Dst:Inter | |Dst:Inter| 242 +---------+ +----------+ ----> +==========+ +---------+ 243 |GRE Header| |GRE Header| 244 +==========+ +==========+ 245 |Src:E/D | |Src:E/D | 246 +==========+ +==========+ 247 |Dst:H | |Dst:H | 248 +==========+ +==========+ 250 <------------- Downstream Traffic 251 +---------+ +----------+ +----------+ +---------+ 252 | Payload | | Payload | | Payload | | Payload | 253 +---------+ +----------+ +----------+ +---------+ 254 |Src:Inter| | Src:Inter| | Src:Inter| |Src:Inter| 255 +---------+ +----------+ +----------+ +---------+ 256 |Dst:CPE C| | Dst:Inter| <----- | Dst:Inter| |Dst:CPE C| 257 +---------+ +==========+ +==========+ +---------+ 258 |GRE Header| |GRE Header| 259 +==========+ +==========+ 260 |Src: H | |Src: H | 261 +==========+ +==========+ 262 |Dst:E/D | |Dst:E/D | 263 +==========+ +==========+ 265 Figure 2: GRE Solution Overview 267 As shown in Figure 2 , particularly, the traffic going to upstream is 268 encapsulated by GRE on CPE and decapsulated on HAAP. On the other 269 side, HAAP encapsulates the downstream traffic by GRE which will be 270 decapsulated on CPE. In order to clarify the details, the traffic 271 forward actions is described following taking the upstream traffic as 272 an example. A Internet service is initiated at CPE, whose source 273 address is Src:CPE C, which is the public address of CPE assigned by 274 HAAP, the destination address is dst: Inter, the specific Internet 275 server address (e.g. google, youtube,etc). Receiving the upstream 276 traffic, CPE encapsulates the packets of the upstream traffic by GRE 277 tunnel, either LTE GRE tunnel header (Src: E and Dst: H) or DSL GRE 278 tunnel header (Src:D and Dst:H) in order to balance the traffic 279 between LTE and DSL network when DSL network is almost fully 280 occupied. When the GRE packets the HAAP, they will be decapsulated 281 and then be forwarded as general IP packets. 283 4. IP Address Assignment 285 4.1. IPv4 Address Assignment 287 The IPv4 address assignment in Figure 2 are shown as follows: 289 o E: CPE LTE WAN Interface IPv4 address (LTE GRE tunnel termination 290 on CPE side ) 292 In LTE network, during Packet Data Protocol (PDP) 293 establishment[TS23.401], the PDN Gateway in LTE network will allocate 294 IPv4 address to CPE LTE WAN interface , referred as E . This IPv4 295 address is used as LTE GRE tunnel termination's IPv4 address on CPE 296 side. 298 o D: CPE DSL WAN Interface IPv4 address (DSL GRE tunnel termination 299 on CPE side) 301 In DSL network, during PPPoE exchanges [RFC2561], it is the DSL 302 gateway (e.g. Broadband Network Gateway (BNG)) responsibility to 303 allocate the IPv4 address to CPE DSL WAN interface. This IPv4 304 address is referred as D, which is used as DSL GRE tunnel 305 termination's IPv4 address on CPE side. 307 o C: CPE Public IPv4 address for route advertisement__ 309 This address is assigned by HAAP acting as DHCPv4 server. CPE 310 advertises this IPv4 address during Interior Gateway Protocol (IGP) 311 exchanges for following service transmit. This is the IPv4 address 312 used for the Internet communication. 314 o H: HAAP IPv4 address (LTE/DSL GRE tunnel termination on HAAP side) 316 This address can be pre-configured statically on HAAP. 318 4.2. IPv6 Address Assignment 320 The IPv6 addresses in Figure 2 are shown as follows: 322 o E: CPE LTE WAN Interface IPv6 prefix (LTE GRE tunnel termination 323 on CPE side) 325 In LTE network the CPE LTE WAN interface gets assigned a specific 326 IPv6 prefix (e.g. /64 prefix) by establishing PDP context with PGW, 327 referred as D in Figure 2. 329 o D: CPE DSL WAN Interface IPv6 prefix (DSL GRE tunnel termination 330 on CPE side) 332 For IPv6 communication, the CPE DSL WAN interface is assigned a 333 specific IPv6 prefix (e.g. /64 prefix) by BNG during PPPoE procedure. 335 o C: CPE IPv6 prefix 337 This IPv6 prefix is assigned by HAAP. This address is stored both on 338 CPE and HAAP. In this case, HAAP will act as DHCPv6 service. 340 o H: HAAP IPv6 prefix (LTE/DSL GRE tunnel termination on HAAP side) 342 This address can be pre-configured statically on HAAP. 344 There may be two routing for terminal host traffic via the same CPE 345 DSL WAN interface, one route is for bypass traffic without arriving 346 HAAP in Section 5.3, the other route is for HYA traffic with arriving 347 HAAP. So there must be two IPv6 address advertisement for one host 348 in Internet. To achieve this purpose, the IPv6 prefix translation is 349 deployed. 351 There are two scenarios: 353 1 DSL GRE Tunnel UP and LTE GRE Tunnel UP 355 Terminal Host will get a IPv6 prefix D-LAN from D prefix via SLAAC 356 [RFC4862]. This prefix is used for DSL bypass traffic route 357 advertisement. 359 IPv6 translation happens on HAAP. On HAAP, the terminal host IPv6 360 prefix D-LAN will be mapped to C, which is CPE IPv6 prefix assigned 361 by HAAP. The C is used for HYA traffic route advertisement. 363 2 DSL GRE Tunnel Down and LTE GRE Tunnel UP 365 Terminal Host will get a IPv6 prefix C-LAN from C prefix via SLAAC 366 [RFC4862]. This prefix is used for DSL bypass traffic route 367 advertisement. 369 IPv6 translation happens on HAAP. On HAAP, the terminal host IPv6 370 prefix C-LAN will be mapped to C, which is CPE IPv6 prefix assigned 371 by HAAP. The C is used for HYA traffic route advertisement. 373 5. GRE Solution Function 375 5.1. GRE Tunnels Setup and Management 377 In this document, the LTE and DSL GRE tunnels described in Figure 2 378 are established by GRE control messages exchanges between CPE and 379 HAAP. The general procedures for the tunnels establishment are 380 illustrated in the following diagram Figure 3. 382 The annotated ladder diagram shows CPE on the left, HAAP on the 383 right. LTE and DSL network support customer traffic transmission as 384 shown in the middle. 386 ========== :::::::::: ========== 387 CPE LTE/DSL HAAP 388 ========== :::::::::: ========== 390 [....CPE obtains LTE WAN IF addreess during PDP from PGW....] 391 [...CPE obtains DSL WAN IF address during PPPoE from BNG...] 392 [.......... CPE obtains HAAP address H via DNS ..........] 394 [.......... begin tunnel establishment and bond............] 396 (........ begin lte gre tunnel establishment.............) 398 ---- GRE Setup Request Message over LTE -------> 399 ** Authentication and Authorization Passed ** 400 <- (1) GRE Setup Accept Message over LTE--------- 401 (carrying session ID) 402 ** Authentication and Authorization Failed ** 403 <-(2) GRE Setup Deny Message over LTE ----------- 404 if (1) 405 (........ lte gre tunnel establishment finishs ...........) 406 if (2) 407 (------------------------ end --------------------------) 409 ---- Request CPE IP Address(C) (DHCP over LTE GRE) ------> 410 <--IP Address (C) Assigned to CPE(DHCP over LTE GRE)------ 412 (........... begin dsl gre tunnel establishment ...........) 414 ----- GRE Setup Request Message over DSL -----> 415 (same session ID acquired during LTE establishment ) 416 ** Authentication and Authorization Passed ** 417 <----(3) GRE Setup Accept Message over DSL ---- 418 ** Authentication and Authorization Failed ** 419 <----(4) GRE Setup Deny Message over DSL ------ 420 If (3) 421 (........ dsl gre tunnel establishment finishes..............) 422 (.......finish tunnel establishment and bond ...............) 423 if (4) 424 (----------------------- end -----------------------------) 426 Figure 3: GRE Tunnel Establishment Procedure 428 The procedure of tunnel establishment is achieved by GRE control 429 message exchanging. Meanwhile, the LTE and DSL GRE tunnels are 430 bonded via the same "session ID" exchanged during the tunnel 431 establishment procedure. 433 The details procedures are shown as follows: 435 1. CPE already gets DSL WAN interface IP address through PPPoE from 436 BRAS and LTE WAN interface IP address through PDP from PGW. 438 2. CPE request DNS resolution for HAAP domain name via DSL WAN or 439 LTE WAN interface, DNS server will return a corresponding HAAP 440 IP address which can be pre-configured by operators. 442 3. Then CPE tries to setup the tunnels and bundling them. CPE will 443 setup LTE GRE tunnel before DSL GRE tunnel. CPE sends GRE 444 Tunnel Setup Request message to HAAP via LTE WAN interface. 446 4. The HAAP receives the message and then iniates the 447 Authentication and Authorization procedure in order to check 448 whether CPE is trusted for PGW. It is similar like UE 449 authentication in [TS23.401]. 451 5. After authentication and authorization succeed, HAAP then 452 replies GRE Tunnel Setup Accept message to CPE via LTE. 453 Specially, Session ID generated randomly by HAAP will be carried 454 in this message, which is used for bonding LTE GRE tunnel and 455 DSL GRE tunnel for one subscriber later.If authentication and 456 authorization failed, HAAP must send the GRE Setup Deny message 457 to CPE over LTE, the tunnel establishment procedure must be tore 458 down. 460 6. After LTE GRE tunnel setup is success, CPE begins to obtain C 461 address defined in Section 4 from HAAP through DHCP over LTE GRE 462 tunnel. At the same time, CPE begins to setup DSL GRE tunnel. 464 7. CPE sends GRE Setup Request message with HAAP address as the 465 destination IP of GRE via DSL WAN interface, carrying the same 466 session ID received from HAAP in Step 5. 468 8. The HAAP receives the message and then initiates the 469 Authentication and Authorization procedure in order to check 470 whether CPE is trusted for BRAS and validate the HYA service 471 rights for CPE. 473 9. After authentication and authorization succeed, HAAP sends GRE 474 Setup Accept message to CPE via DSL. CPE then bundle the two 475 GRE tunnels based on same Session ID. 477 10. CPE sends GRE Notify message via DSL WAN immediately after the 478 DSL GRE tunnel setup successfully in order to inform the DSL 479 bypass bandwidth to HAAP. More details is shown in Section 6. 481 For management and control motivations, GRE tunnel management process 482 message exchanges between CPE and HAAP are needed, shown in the 483 following figureFigure 4. 485 ========== :::::::::: ========== 486 CPE LTE/DSL HAAP 487 ========== :::::::::: ========== 489 (..... lte/dsl tunnel failure detection and keepalive...) 490 --------- GRE Hello Message over LTE --------> 491 <--------- GRE Hello Message over LTE --------- 492 ---------- GRE Hello Message over DSL --------> 493 <--------- GRE Hello Message over DSL --------- 495 (..........lte/dsl tunnel information inform.............) 496 ---------- GRE Notify Message over LTE--------> <--------- 497 GRE Notify Message over LTE -------- ---------- GRE 498 Notify Message over DSL--------> <--------- GRE Notify 499 Message over DSL -------- 501 ( ......... lte/dsl tunnel teardown ....................) 502 <--------- GRE Tear Down Message over LTE -------- 503 <--------- GRE Tear Down Message over DSL -------- 505 Figure 4: GRE Tunnel Management Procedure 507 GRE Hello messages exchange between CPE and HAAP for LTE/DSL tunnel 508 failure detection and keep-alive. GRE Notify message is used to 509 inform status/information (e.g., dsl network status, service list for 510 HYA, etc) between CPE and HAAP. A notify acknowledgement (ACK) via 511 GRE Notify message and retransmission mechanism can be used to 512 provide certain level reliable transport capability. For maintenance 513 reasons, GRE Tear Down message can be used by HAAP to terminate the 514 bond LTE GRE tunnel and DSL GRE tunnel for some reasons because of 515 network failures. The detailed control messages are proposed in 516 Section 6.1. 518 5.2. Packet-Based Traffic Overflow 520 In this document, traffic distribution between the established and 521 bond LTE and DSL GRE tunnel is packet-based overflow.The packet-based 522 traffic overflow machinism includes two requirements, cheapest path 523 used first (e.g., DSL GRE tunnel Figure 2 )and traffics overflowed 524 when cheapest path is almost fully occupied. To satisfy these 525 requirements,Two Rate Three Color Marker (trTCM) [RFC2698]can be 526 used. 528 Two token buckets based on DSL and LTE resource are used to meter if 529 the packets is overflowed or not. The details rate configuration is 530 based on the operators' requirement, which is out of the scope. 531 Clearly,the packet can be marked with yellow if the packet is 532 overflowed, otherwise the packet is marked with green based on 533 [RFC2698]. Then the colored based policy routing is executed on CPE 534 and HAAP. The packet will be routed into the corresponding tunnel 535 based on the marked color. For example, yellow color packet will be 536 routed to LTE GRE tunnel; green color packet will be routed into DSL 537 GRE tunnel.The GRE IP headed is used to encapsulate the traffic on 538 CPE and HAAP as shown in . (Figure 2). 540 On the received side, the packets encapsulated in GRE will come from 541 DSL GRE tunnel and/or LTE GRE tunnel. Due to different transporting 542 delivery caused by LTE and DSL paths, the packets in the same flow 543 may reach out of the order. Consequentially the packets will be sent 544 to a buffer for reordering based on the sequence information in GRE 545 header, details in Section 6. After reordering, the GRE header will 546 be removed and the packet will be sent to the ordinary IP packet 547 processing. 549 5.3. Backward Compatibility 551 The solution should satisfy the backward compatibility requirements. 552 While deploying HYA architecture, the existing services must not be 553 influenced. For example, IPTV traffic must be remained into the DSL 554 path only for performance reasons, instead of LTE tunnel. In 555 addition some control messages (e.g. for TR069/ACS, DNS etc.) might 556 not be reachable through the HAAP as well due to control and 557 management entities deployment scenario in the network. These kinds 558 of services can be defined and managed by operators during HYA 559 deployment. 561 In this document, the mechanism must be defined for deploying and 562 maintaining the list of these kinds of traffic. The negotiation 563 between HG and HAAPFigure 5 is described for this purpose. 565 During network arrangement, operators may configure this service 566 list. HAAP provision the information to CPE via LTE/DSL GRE tunnel. 567 And the list must be updateable during the established tunnel. At 568 each time when CPE try to establish the tunnel, the list is pushed by 569 HAAP. CPE will flash the the list if it have a previous one. If the 570 list is taken some errors during list flashing, CPE should keep the 571 previous one and reply the error code to HAAP via GRE Notify 572 message.The errors include download unsuccessfully, incorrect format, 573 wrong syntax etc defined in Section 6. 575 ========== :::::::::: ========== 576 CPE LTE/DSL HAAP 577 ========== :::::::::: ========== 578 <--------- GRE Notify Message (Filter list TLV) --------- 579 ---------- GRE Notify Message (ACK or Errors) ----------> 581 Figure 5: GRE Tunnel Service List Management 583 As shown Figure 5, only one GRE tunnel (LTE/GRE) will be used for one 584 time transmission of GRE Notify message carrying the service list, 585 and each notification will be replied by a notification ACK.If 586 several times of transmission failure for notification, the tunnel 587 for sending notification will be switched to the other one. 589 HG will validate the received filter list packet, if no error found, 590 CPE will reply GRE Notify message as ACK to HAAP. So HAAP directly 591 stops to send the following filter list packet, that means this time 592 of filter list notification is completed successfully. If any error 593 found, CPE will reply GRE Notify message as errors feedback, HAAP 594 will try to send it again or stop it. The details are described in 595 Section 6. 597 In case of large size of the service list, multiple GRE Notify 598 messages to CPE are needed to carry multiple fragments of the list. 599 Each of these GRE Notify message needs a notification ACK. 601 5.4. Bypassing Traffic Statistic 603 Bypassing Traffic means that the traffic MUST bypass the HYA GRE 604 tunnel but directly over DSL WAN interface as mentioned filter list 605 in Section 5.3, and this happens on the CPE. The traffic bypass 606 behavior is accomplished by implementing a routing table on CPE. 607 Distinctly, part of DSL bandwidth is already occupied by these types 608 of bypass traffic with higher priority. As a result, only the DSL 609 bandwidth left can be used for HYA DSL GRE tunnel. 611 The solution must consider how to meter the bypassing traffic 612 statistic on DSL bandwidth and adjust the free resource left in DSL 613 for HYA. The DSL bandwidth for HYA must be adjusted dynamically when 614 bypass traffics are presenting. CPE can check the bypass traffic 615 rate periodically, and notify the parameters to the HAAP. HAAP can 616 adjust the token buckets for packet overflow action later on defined 617 in Section 5.2. 619 5.5. LTE and DSL Path Difference Consideration 621 In HYA, LTE and DSL tunnel may have different characters, such as 622 rates, delay and MTU which cause the throughput and traffic 623 fragmentation issues. These differences should be considered during 624 the GRE solution design. 626 The rate, Round Trip Time (RTT) /delay of a DSL link is relatively 627 fixed, but the RTT/delay character of an LTE link vary over time. 628 When the DSL and LTE link are combined in HYA, the CPE has a larger 629 combined bandwidth (DSL_BW + LTE_BW), but the RTT/delay of the bonded 630 tunnels may become bigger for customer traffics. The maximum RTT/ 631 delay of customer HYA traffic is equal to bigger one of the LTE and 632 DSL links. Usually, the buffering size for packet reorder is related 633 to the RTT/delay difference between both LTE and DSL link. If the 634 RTT/delay difference is too big, the buffer size will be too huge to 635 be achieved on CPE/HAAP. In this case, the bandwidth efficiency of 636 the HYA will disappeared comparing the bigger RTT/delay and huge 637 buffer requirement. 639 The MTU difference may impact the packet fragmentation and reorder. 640 The minimum MTU on DSL path is PPPoE MTU, which is 1492. The minimum 641 MTU on LTE path is UGW MTU, which is 1436. In HYA, the maxium tunnel 642 MTU is LTE MTU minus GRE overhead. Static calculation for GRE tunnel 643 MTU sized based on DSL path MTU and LTE path MTU is configured. MSS 644 adjustment for TCP on CPE based on the calculation in order to avoid 645 IP fragmentation on both GRE outer IP layer and inner IP layer. 647 6. GRE Control Message Definition 649 In this section, GRE encapsulation control messages are defined for 650 negotiation between CPE and HAAP for the LTE and DSL tunnel 651 establishment, bond, management, etc, which are not standardized yet. 652 The GRE control messages format are according to [RFC2890]. The GRE 653 header as described inFigure 6 indicates a control protocol with the 654 Protocol Type section set to 0x0101 in this document. 656 0 1 2 3 657 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 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 |C| |K|S| Reserved0 | Ver | Protocol Type | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Key | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 |MsgType|T| Res |Attribute Type | Attribute Length | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Attribute Value | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 Figure 6: GRE Header Format 670 Protocol Type (2 octets) 672 The Protocol Type field identifies the GRE protocol for HYA network. 673 The value 0x0101 is proposed. 675 Message Type (MesType) (4 bits) 677 The Message Type field identifies GRE protocol control messages for 678 HYA network. Right now, there are 6 valid types of GRE control 679 message mentioned , shown as belowFigure 7: 681 Control Message Family Type 682 ========================= ============ 684 GRE Setup Request 1 685 GRE Setup Accept 2 686 GRE Setup Deny 3 687 GRE Hello 4 688 GRE Tear Down 5 689 GRE Notify 6 690 Reserved 0,7-15 692 Figure 7: GRE Control Messages 694 Tunnel Type (T) (1 bit) 696 If the Tunnel Type bit is set to 1, then it indicates that this 697 control message is used for the DSL GRE tunnel. Otherwise it 698 indicates that this control message is used for the LTE GRE tunnel. 700 Attribute Type (1 octet) 702 Attribute Type indicates the type of the appended attributes included 703 in the GRE header. The types of attributes are defined in Section 7. 705 Attribute Length (2 octets) 707 Attribute Length field indicates the length of the attribute by byte. 709 Attribute Value (variable) 711 Attribute Value field includes the value of the attribute. 713 6.1. GRE Setup Request Message 715 GRE Setup Request message is sent by CPE to HAAP via LTE and DSL WAN 716 in order to set up LTE and DSL GRE tunnel. 718 The following attributions MUST be included in the GRE Setup Request 719 Message. 721 o Client Identification Name (CIN) Figure 10. Only the GRE Tunnel 722 Setup Requst Message through LTE WAN must contain the CIN. 724 o Session ID Figure 11. CPE must encapsulate the Session ID 725 attribute in GRE Setup Request message via DSL WAN. This Session 726 ID is genernated by HAAP during LTE tunnel establishment Figure 3. 727 The value in Session ID attribute must be same via both DSL and 728 LTE WAN. In addition, when LTE GRE tunnel recovery from failure 729 while DSL GRE tunnel exists, the re-established LTE tunnel request 730 needs to carry the Session ID Attribute. 732 o End AVP, see Section 7. 734 6.2. GRE Setup Accept Message 736 HAAP sends GRE Setup Accept Message to CPE if HAAP accepts associated 737 GRE Setup Request from CPE. The routing path of a pair of GRE Setup 738 Request message and GRE Setup Accept message must be the same, either 739 LTE or DSL. 741 The following attributions MUST be included in the GRE Setup Accept 742 Message via LTE WAN. 744 o Session IDFigure 11, HAAP generates a session ID for a CPE and 745 sends the Session ID attribute to CPE LTE WAN via GRE Setup Accept 746 Message. 748 o RTT Difference Threshold AttributeFigure 16, see Section 7.6. 750 o Bypass Bandwidth Check IntervalFigure 17, see Section 7.7. 752 o Hello IntervalFigure 18, see Section 7.10. 754 o Hello Retry TimesFigure 19, see Section 7.11. 756 o Idle TimeoutFigure 20, see Section 7.12. 758 o Delay Difference Threshold Violation, see Section 7.19 760 o Delay Difference Threshold Compliance, see Section 7.20 762 o End AVP, see Section 7.22 764 The following attributions MUST be included in the GRE Setup Accept 765 Message via DSL WAN. 767 o Subscribed DSL Upstream BWFigure 23, see Section 7.17. 769 o Subscribed DSL Downstream BWFigure 24, see Section 7.18. 771 o End AVP, see Section 7.22 773 6.3. GRE Setup Deny Message 775 HAAP will send GRE Setup Deny Message to CPE through LTE and/or DSL 776 path if HAAP denies the GRE Setup Request for LTE and/or DSL GRE 777 tunnel from CPE. 779 The following attributions MUST be included in the GRE Setup Deny 780 Message. 782 o Error CodeFigure 21, see Section 7.13. 784 o End AVP, see Section 7.22. 786 6.4. GRE Hello Message 788 The GRE Hello Message is used for CPE and HAAP on both LTE GRE tunnel 789 and DSL GRE tunnel for failure detection and keepalive of the tunnel. 791 The following attributes MUST be included in the GRE Hello Message. 793 o TimestampFigure 12, see Section 7.3. 795 o End AVP, see Section 7.22. 797 6.5. GRE Tear Down Message 799 GRE Tear down message is used to maintain the state and can only be 800 send from HAAP to CPE to terminate the established LTE and/or DSL 801 tunnels. 803 The following attributes MUST be included in the GRE Tear Down 804 Message. 806 o Error CodeFigure 21, see Section 7.13. 808 o End AVP, see Section 7.22. 810 6.6. GRE Notify Message 812 GRE notify message is used to inform status/information changing and 813 the filter list information between CPE and HAAP. 815 The following attributes MUST be included in the GRE Notify Message 816 via both LTE and DSL WAN. 818 o End AVP, see Section 7.22. 820 The following attributes MAY be included in the GRE Notify Message 821 via LTE WAN . 823 o Filter list packageFigure 14, see Section 7.5. 825 o DSL link failure, see Section 7.14. 827 o IPv6 prefix assigned to terminal hostFigure 22, see Section 7.16. 829 o Filter list ACKFigure 14, see Section 7.21. 831 The following attributes MAY be included in the GER Notify Message 832 via DSL WAN. 834 o Bypass traffic rateFigure 13, see Section 7.4. 836 o Filter list packageFigure 14, see Section 7.5. 838 o Switching to DSL tunnel, see Section 7.8. 840 o Overflowing to LTE tunnel, see Section 7.9. 842 o LTE link failure, see Section 7.15. 844 o IPv6 prefix assigned to terminal hostFigure 22, see Section 7.16. 846 o Filter list ACKFigure 14, see Section 7.21. 848 7. GRE Control Message Attribute Definitions 850 All the attributions are identified by the Type, Length, Value field, 851 shown as below Figure 8.The 8-bits Type field identifies the type of 852 the attribution. 854 0 1 2 3 855 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 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 |Attribute Type | Attribute Length |Attribute Value| 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Attribute Value...... | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 Figure 8: GRE Control Message Attribute Definitions 864 The following GRE control message attributes for HYA are defined in 865 this documentFigure 9 . 867 Control Message Family Type 868 ========================= ============ 870 CIN 3 871 Session ID 4 872 Timestamp 5 873 Bypass Traffic Rate 6 874 Filter List Package 8 875 RTT Difference Threshold 9 876 Bypass Bandwidth Check Interval 10 877 Switching to DSL Tunnel 11 878 Overflowing to LTE Tunnel 12 879 Hello Interval 14 880 Hello Retry Times 15 881 Idle Timeout 16 882 Error Code 17 883 DSL Link Failure 18 884 LTE Link Failure 19 885 IPv6 Prefix Assigned to Terminal Host 21 886 Subscribed DSL Upstream BW 22 887 Subscribed DSL Downstream BW 23 888 Delay Difference Threshold Violation 24 889 Delay Difference Threshold Compliance 25 890 Filter list ACK 30 891 End AVP 255 892 Reserved 894 Figure 9: GRE Control Message Attributes 896 7.1. Client Identification Name (CIN) 898 CIN is used to identified the RG in operator network. CIN is sent to 899 HAAP by CPE for authentication and authorization purpose. It is 900 similar like UE authentication in [TS23.401].Any CPE must transmit a 901 CIN during the tunnel request procedure for authentication. CIN must 902 be unique for each CPE in operator's network. 904 The attribute contains the following value Figure 10: 906 0 1 2 3 907 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 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | CIN | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 Figure 10: CIN Attribute 914 Type:3 for CIN Attribute 916 Length: 40 Bytes 918 CIN: String defined by operators 920 7.2. Session ID 922 Session ID attribute is used to bind the DSL tunnel and LTE tunnel 923 together for individual CPE. Session ID 32bit value is generated by 924 HAAP, and unique within a HAAP. It is used to identify a certain 925 subscriber CPE. 927 HAAP sends this attribute to requesting CPE LTE WAN via GRE Setup 928 Accept message, then CPE encapsulates this attribute in GRE Setup 929 Request through DSL WAN. With this information, CPE and HAAP can 930 bind these two tunnels together. When LTE recovery from failure with 931 DSL tunnel exists, the re-established LTE tunnel request needs to 932 carry the Session ID. 934 The attribute contains the following value Figure 11: 936 0 1 2 3 937 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 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | Session ID | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 Figure 11: Session ID Attribute 944 Type:4 for Session ID Attribute 946 Length: 4 Bytes 948 Session ID: String value generated by HAAP to identify a certain CPE. 950 7.3. Timestamp 952 The Timestamp attribute is used for Round-Trip Time (RTT) RTT 953 calculation. 955 The attribute contains the following value Figure 12. 957 0 1 2 3 958 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 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | Timestamp_second | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | Timestamp_millisecond | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 Figure 12: Timestamp Attribute 967 Type:5 for Timestamp Attribute 969 Length: 8 Bytes 971 Session ID: The higher order 4 bytes is seconds, the low-order 4 972 bytes is millisecond 974 7.4. Bypass Traffic Rate 976 The Bypass Traffic Rate attribute is used by HG to notify HAAP of the 977 bypass traffic rate on CPE, such as IPTV, DNS, etc, see Section 5.4 978 for details. HAAP will calculate the available DSL bandwidth for HYA 979 DSL GRE tunnel based on this information. 981 The attribute contains the following valuesFigure 13. 983 0 1 2 3 984 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 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Bypass Traffic Rate | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 Figure 13: Bypass Traffic Rate Attribute 991 Type:6 for BypassTraffic Rate Attribute 992 Length: 4 Bytes 994 Bypass Traffic Rate: A 4-bytes length integer to identify the 995 resource already occupied in DSL by kinds of bypass traffic referred 996 as Section 5.4 .The CPE will check the bypass traffic rate 997 periodically, if the bypass traffic rate difference is greater than 998 specified percentage of the DSL bandwidth, and then notify the bypass 999 traffic rate to the HAAP. HAAP can adjust the token buckets for 1000 packet overflow action later on Section 5.4. 1002 7.5. Filter List Package 1004 The Filter List Package is the collection of the services list which 1005 MUST not be routed through HYA, but directly over the specific 1006 interface mentioned in Section 5.3. The filter service list is 1007 configured on CPE by HAAP. This attribute is the collection of 1008 filter list TLVs, each TLV carries one kinds of filter service list. 1010 The attribute contains the following valuesFigure 14: 1012 0 1 2 3 1013 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 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | commit_count | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | packt_sum | packt_id | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | type | length | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | enable | description length | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | description value | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 * value (0-256 bits) * 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 Figure 14: Filter List Package Attribute 1030 Type: 8 for Filter List Package Attribute 1032 Length: <= 969 Bytes 1034 Commit_count: It is used to identify the Filter list version. If the 1035 Filter list recieved from HAAP changed, the commit_count will be 1036 updated. CPE will refresh the previous filter list. 1038 Packet_sum: If the filter list packet is larger than the MTU and 1039 should be divided into multiple fragments, the Packet_sum indicate 1040 the fragments numbers of the filter list packet. 1042 Packet_ID: The index of the multiple fragments. 1044 Type: Several filter list type can be defined, which is described as 1045 followingFigure 15. 1047 Length: The length of the specific type of filter list. 1049 Enable: Indicate this type of filter list is enabled. Only can be 1050 1(Enabled) or 0 (Unenabled), other values are reserved. 1052 Description Length: The length of this type of filter list 1053 description, the unit is byte. 1055 Description Value:The value of this type of the filter list 1057 Value: Value of the specific type of filter list. 1059 Filter List Type 1060 ========================= ============ 1061 Fully Qualified Domain Name 1 1062 DSCP 2 1063 Destination Port 3 1064 Destination IP 4 1065 Destination IP&Port 5 1066 Source Port 6 1067 Source IP 7 1068 Source IP&Port 8 1069 Source Mac 9 1070 Protocol 10 1071 Source IP Range 11 1072 Destination IP Range 12 1073 Source IP Range&Port 13 1074 Destination IP Range&Port 14 1075 Reserved 1077 Figure 15: Filter List Type 1079 7.6. RTT Difference Threshold 1081 The difference RTT/delay between DSL and LTE should impact the HYA 1082 network efficiency, mentioned in Section 5.5. So the acceptable RTT 1083 difference threshold in HYA must be defined. This value is signed to 1084 CPE by HAAP. When the RTT difference exceeds the configured RTT 1085 difference threshold, CPE may changing the traffic distribution into 1086 DSL only rather than LTE GRE tunnel. 1088 The attribute contains the following valuesFigure 16 1090 0 1 2 3 1091 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 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | RTT Difference Threshold | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 Figure 16: RTT Difference Threshold 1098 Type: 9 for RTT Difference Threshold Attribute 1100 Length: 4 Bytes 1102 RTT Difference Threshold: The unit of this integer value is ms 1103 (milliseconds). This value is configurable, the value range can be 1104 from 0~1200ms, changing step is 1ms. 1106 7.7. Bypass Bandwidth Check Interval 1108 The Bypass Bandwidth Check Interval is assigned to CPE by HAAP. Based 1109 on requirement in Section 5.4, CPE will check the bypass bandwidth on 1110 DSL path after this interval. 1112 The attribute contains the following valueFigure 17: 1114 0 1 2 3 1115 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 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Bypass Bandwidth Check Interval | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 Figure 17: Bypass Bandwidth Check Interval Attribute 1122 Type: 10 for Bypass Bandwidth Check Interval Attribute 1124 Length: 4 Bytes 1126 Bypass Bandwidth Check Interval: Integer as seconds. This value is 1127 configurable, the range is from 10-300s, changing step is 1s. 1129 7.8. Switching to DSL Tunnel 1131 The Switching to DSL Tunnel is used by CPE to notify HAAP to switch 1132 the traffic to DSL only. When the RTT difference between DSL and LTE 1133 tunnel exceeds the RTT difference thresholdFigure 16 3 times (default 1134 value), the CPE will send a Notify message with "Switching to DSL 1135 tunnel" attribute to HAAP. Then the traffic will be sent through the 1136 DSL tunnel only no matter HAAP or CPE. 1138 There is no value in this attribute. 1140 Type: 11 for Switching to DSL Tunnel 1142 Length: 0 1144 7.9. Overflowing to LTE Tunnel 1146 The Overflowing to LTE Tunnel is used by CPE to notify HAAP to 1147 overflow the traffic to LTE tunnel. When the RTT difference between 1148 DSL and LTE tunnel is lower than the RTT difference 1149 thresholdFigure 16 3 times (default value), the CPE will send a a 1150 Notify message with "Overflowing to LTE tunnel" attribute to HAAP. 1151 Then the traffic can overflow to the LTE tunnel. 1153 There is no value in this attribute. 1155 Type: 12 for Overflowing to LTE Tunnel 1157 Length: 0 1159 7.10. Hello Interval 1161 The Hello Interval is configured to CPE by HAAP. The GRE Hello 1162 message between CPE and HAAP will be negotiated in each hello 1163 interval period. 1165 The attribute contains the following valueFigure 18: 1167 0 1 2 3 1168 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 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 | Hello Interval | 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 Figure 18: Hello Interval Attribute 1175 Type: 14 for Hello Interval Attribute 1176 Length: 4 Bytes 1178 Hello Interval: Integer. The unit of this value is second. This 1179 value should be configurable, with range 1~100s, changing step is 1s. 1181 7.11. Hello Retry Times 1183 The Hello Retry Times is configured to CPE by HAAP. The GRE Hello 1184 message between CPE and HAAP will be retried several times defined in 1185 this atrribute. 1187 The attribute contains the following valueFigure 19. 1189 0 1 2 3 1190 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 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | Hello Retry Times | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 Figure 19: Hello Retry Times Attribute 1197 Type: 15 for Hello Retry Times Attribute 1199 Length: 4 Bytes 1201 Hello Retry Times: Integer. It is the times about the GRE Hello 1202 Message retry. This value is configurable, the value range is from 1203 3~10, changing step is 1. 1205 7.12. Idle Timeout 1207 The Idle Timeout is configured on CPE by HAAP. If GRE tunnels are 1208 already established via DSL and LTE, idle timeoutFigure 28 will 1209 occur. All tunnels must be terminated if LTE/DSL tunnel isn't 1210 restored within a period time (e.g., idle timeout). 1212 The attribute contains the following valueFigure 20. 1214 0 1 2 3 1215 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 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 | Idle Timeout | 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 Figure 20: Idle Timeout Attribute 1222 Type: 16 for Idle Timeout Attribute 1223 Length: 4 Bytes 1225 Idle Timeout: Integer. The unit of this value is seconds. The value 1226 is configurable, with range from 0~172800s, step is 60s. 1228 7.13. Error Code 1230 The Error Code is used when the erros happens in HYA network. 1232 The attribute contains the following valueFigure 21. 1234 0 1 2 3 1235 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 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 | Error Code | 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 Figure 21: Error Code Attribute 1242 Type: 17 for Error Code Attribute 1244 Length: 4 Bytes 1246 Idle Timeout: Integer. Error cases have to be handled. 1248 7.14. DSL Link Failure 1250 The DSL Link Failure will be used by CPE to inform HAAP of CPE DSL 1251 link failure through LTE WAN. Usually, the failure can be detected 1252 by HAAP via GRE Hello message. However, it is possible that the 1253 local failures happen on CPE. In this case, direct notification to 1254 HAAP is a efficiency way than GRE hello mechanism (Failure Detection 1255 time is retry times*hello interval) 1257 There is no value in this attribute. 1259 Type: 18 for DSL Link Failure 1261 Length: 0 1263 7.15. LTE Link Failure 1265 The LTE Link Failure will be used by CPE to inform HAAP of CPE LTE 1266 link failure through DSL WAN. Usually, the failure can be detected 1267 by HAAP via GRE Hello message. However, it is possible that the 1268 local failures happen on CPE. In this case, direct notification to 1269 HAAP is a efficiency way than GRE hello mechanism (Failure Detection 1270 time is retry times*hello interval) 1272 There is no value in this attribute. 1274 Type: 19 for LTE Link Failure 1276 Length: 0 1278 7.16. IPv6 Prefix Assigned to Terminal Host 1280 The IPv6 Prefix assigned to terminal host on CPE will be notified to 1281 HAAP. Then HAAP can setup the IPv6 prefix translation mapping 1282 between CPE HA IPv6 prefix and the terminal host IPv6 prefix. When 1283 the downstream traffic arriving, HAAP can advertise the CPE HA IPv6 1284 prefix for HYA refereed to Section 4.2. 1286 When both DSL link and LTE link are working, CPE will assign BRAS 1287 IPv6 prefix to terminal host. When DSL line failure and lead to 1288 PPPoE terminated, CPE will assign HAAP IPv6 prefix to terminal host. 1289 When DSL line recovers from failure and obtains a new IPv6 prefix 1290 from BRAS, CPE will assign BRAS IPv6 prefix to terminal host again. 1291 When HG change the IPv6 prefix assigned to terminal host, need to 1292 send notify to HAAP. 1294 The attribute contains the following valueFigure 22: 1296 0 1 2 3 1297 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 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 \ IPv6 Prefix Assigned to Terminal Host \ 1300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 | Network Mask | 1302 +-+-+-+-+-+-+-+-+ 1304 Figure 22: IPv6 Prefix Assigned to Terminal Host Attribute 1306 Type: 21 for IPv6 Prefix Assigned to Terminal Host Attribute 1308 Length: 17 Bytes 1310 Value: The first 16 bytes are the IPv6 prefix, the last byte 1311 indicates the network mask. 1313 7.17. Subscribed DSL Upstream BW 1315 The Subscribed DSL Upstream BW is used by HAAP to notify CPE the 1316 available DSL upstream Bandwidth. The subscribed DSL Upstream BW can 1317 be obtained by HAAP during authentication and authorization process. 1318 CPE/HAAP will use this value to set the token bucket on DSL for 1319 traffic overflow referred to Section 5.4. 1321 The attribute contains the following valueFigure 23 1323 0 1 2 3 1324 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 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | Subscribed DSL Upstream BW | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 Figure 23: Subscribed DSL Upstream BW 1331 Type: 22 for Subscribed DSL Upstream BW 1333 Length: 4 Bytes 1335 Subscribed DSL Upstream BW: The conventional DSL upstream BW is 1336 provided by operator for CPE.The unit of this value is kbps. 1338 7.18. Subscribed DSL Downstream BW 1340 The Subscribed DSL Downstream BW is used by HAAP to notify CPE the 1341 available DSL downstream Bandwidth. The subscribed DSL Downstream BW 1342 can be obtained by HAAP during authentication and authorization 1343 process. CPE/HAAP will use this value to set the token bucket on DSL 1344 for traffic overflow referred to Section 5.4. 1346 The attribute contains the following valueFigure 24: 1348 0 1 2 3 1349 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 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 | Subscribed DSL Downstream BW | 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 Figure 24: Subscribed DSL Downstream BW 1356 Type: 23 for Subscribed DSL Downstream BW 1358 Length: 4 Bytes 1359 Subscribed DSL Downstream BW: The conventional DSL downstream BW is 1360 provided by operator for CPE. The unit of this value is kbps. 1362 7.19. Delay Difference Threshold Violation 1364 The Delay Different Threshold Violation is used to carry the times 1365 when the RTT/delay difference exceeds the threshold defined in Figure 1366 16. This times will impact the decision to switch the traffic to DSL 1367 GRE tunnel only. When the RTT/delay difference exceeds the threshold 1368 above the times defined in this attribute, all the traffic will be 1369 switched to DSL tunnel, rather than LTE tunnel. This is the 1370 configuration to CPE by HAAP. 1372 The attribute contains the following valueFigure 25. 1374 0 1 2 3 1375 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 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | Delay Difference Threshold Violation Times | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 Figure 25: Delay Difference Threshold Violation 1382 Type: 24 for Delay Difference Threshold Violation Attribute 1384 Length: 4 Bytes 1386 Delay Difference Threshold Violation Times: The times when the RTT/ 1387 delay difference exceeds the threshold defined in Figure 16. This 1388 value can be configured by operators. 1390 7.20. Delay Difference Threshold Compliance 1392 The Delay Different Threshold Compliance is used to carry the times 1393 when the RTT/delay difference stays below the threshold defined in 1394 Figure 16. This times will impact the decision to switch the traffic 1395 to DSL GRE tunnel only.When the RTT/delay difference stays below the 1396 threshold above the times defined in this attribute, all the traffic 1397 can be transmitted over HYA, with both LTE and DSL tunnel. This is 1398 the configuration to CPE by HAAP. 1400 The attribute contains the following valueFigure 26. 1402 0 1 2 3 1403 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 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | Delay Difference Threshold Compliance Times | 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 Figure 26: Delay Difference Threshold Compliance 1410 Type: 25 for Delay Difference Threshold Compliance Attribute 1412 Length: 4 Bytes 1414 Delay Difference Threshold Compliance Times: The times when the RTT/ 1415 delay difference stays below the threshold defined in Figure 16. This 1416 value can be configured by operators. 1418 7.21. Filter list ACK 1420 The Filter List ACK attribute is defined for acknowledgement of 1421 filter list notify and filter list error notification. This 1422 attribute is used as a reply for Figure 14. 1424 The attribute contains the following value Figure 27. 1426 0 1 2 3 1427 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 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 | commit_count | 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 | Error Code | 1432 +-+-+-+-+-+-+-+-+-+-+-+-+ 1434 Figure 27: Filter List ACK Attribute 1436 Type: 30 for Filter List ACK Attribute 1438 Length: 5 Bytes 1440 Commit_count: The first 4 bytes is committed count, to differentiate 1441 filter list packages in case of change of the filter list package. 1443 Error Code: Code 0 is ACK; code 1 is NACK and indicates this is new 1444 dial-in subscriber, which means HAAP should teardown this user to let 1445 this user to redial; code 2 is NACK and indicates this is a existing 1446 subscriber, HAAP should sent the filter list package to this 1447 subscriber again. 1449 7.22. End AVP 1451 The End AVP is used to indicate that this is the last attribute 1452 contained in the GRE control messages. There is no value in End AVP. 1454 Type: 255 for End AVP 1456 Length: 0 1458 8. GRE Tunnels State Machine 1460 The following state diagram (Figure 28) represents the life cycle of 1461 HYA bonding tunnel. 1463 +------------TUNNEL UP--------------+ 1464 | | 1465 /-+-\ /-V-\ 1466 + LTE UP--> +-DSL UP+ +-------> +-------+ 1467 | | 6 | | DSL DOWN| 7 |LTE DOWN 1468 | \---/ | TUNNEL | \-+-/ | 1469 /-+-\ /-V-\ UP /-+-\ | /-V-\ 1470 | | | +-------> <-DSL UP+ | | 1471 | 1 | | 3 | | 4 <-LTE UP+ | 8 | 1472 \^+-/ \-^-/ \-+-/ | \-^+/ 1473 || | | | || 1474 || | | | DSL DOWN| 1475 || /---\ | LTE DOWN /-+-\ || 1476 |+-DSL UP--> +-LTE UP+ +-------> +-------+| 1477 | | 2 | | 5 | | 1478 | \-^-/ \-+-/ | 1479 | | TUNNEL DOWN IDLE TIMEOUT | | 1480 | +-----------------------------------+ | 1481 +-------------------------------------------------------------+ 1482 TUNNEL DOWN 1484 Figure 28: GRE State Machine 1486 The various states are described as below: 1488 State No. DSL Tunnel LTE Tunnel Bonding Tunnel 1489 ========= =========== =========== =============== 1491 1 Down Down Down 1492 2 Up Down Down 1493 3 Up Up Down 1494 4 Up Up Up 1495 5 Up Down Up 1496 6 Down Up Down 1497 7 Down Up Up 1498 8 Down Down Up 1500 Tunnel / GRE States 1502 9. IANA Considerations 1504 IANA is requested to allocate one code TBD for the dynamic GRE 1505 protocol. 1507 10. Security Considerations 1509 In the whole processing of HA, security of control messages MUST be 1510 guaranteed. The CPE discovers the HAAP by resolving the HAAP address 1511 over DNS. This protects the CPE against connections to foreign HAAP, 1512 if the DNS service and the domain name in the CPE isn't corrupted. 1514 The CPE should be prevented against receiving GRE notifications 1515 without a valid session In the whole processing of end to end HAAP 1516 session establishing and GRE notification signaling, the source IP 1517 address for session establishment from CPE MUST be strictly verified, 1518 including IP address authentication and identification at the HAAP 1519 side. Any authentication mechanism with credential or checking the 1520 IP address is feasible. 1522 GRE notification key poisoning Every new session at the HAAP 1523 generates a magic number, which is encapsulated in the key field of 1524 the GRE header and will be carried in the signalling messages and 1525 data traffic for verification by comparing the Magic Number in the 1526 message and the Magic Number in the local session table. Traffic 1527 without a valid Magic Number and outer IP address will be discarded 1528 on the HAAP. Magic number is used for both control message and data 1529 message security. 1531 For data traffic security, it is also proposed to use IP address 1532 validation to protect against IP Spoofing attacks. 1534 11. Acknowledgements 1536 Many thanks to Dennis Kusidlo. 1538 12. Normative References 1540 [I-D.lhwxz-hybrid-access-network-architecture] 1541 Leymann, N., Heidemann, C., Wasserman, M., and D. Zhang, 1542 "Hybrid Access Network Architecture", draft-lhwxz-hybrid- 1543 access-network-architecture-00 (work in progress), June 1544 2014. 1546 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1547 Requirement Levels", BCP 14, RFC 2119, March 1997. 1549 [RFC2561] White, K. and R. Moore, "Base Definitions of Managed 1550 Objects for TN3270E Using SMIv2", RFC 2561, April 1999. 1552 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 1553 Marker", RFC 2697, September 1999. 1555 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 1556 Marker", RFC 2698, September 1999. 1558 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 1559 RFC 2890, September 2000. 1561 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1562 Address Autoconfiguration", RFC 4862, September 2007. 1564 [TS23.401] 1565 "3GPP TS23.401, General Packet Radio Service (GPRS) 1566 enhancements for Evolved Universal Terrestrial Radio 1567 Access Network (E-UTRAN) access", September 2013. 1569 Authors' Addresses 1571 Nicolai Leymann 1572 Deutsche Telekom AG 1573 Winterfeldtstrasse 21-27 1574 Berlin 10781 1575 Germany 1577 Phone: +49-170-2275345 1578 Email: n.leymann@telekom.de 1579 Cornelius Heidemann 1580 Deutsche Telekom AG 1581 Heinrich-Hertz-Strasse 3-7 1582 Darmstadt 64295 1583 Germany 1585 Phone: +4961515812721 1586 Email: heidemannc@telekom.de 1588 Margaret Wesserman 1589 Painless Security 1591 Email: mrw@painless-security.com 1593 Li Xue 1594 Huawei 1595 NO.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan 1596 Beijing, HaiDian District 100095 1597 China 1599 Email: xueli@huawei.com 1601 Mingui Zhang 1602 Huawei 1603 NO.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan 1604 Beijing, HaiDian District 100095 1605 China 1607 Email: zhangmingui@huawei.com