idnits 2.17.1 draft-softwire-gateway-init-ds-lite-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 11, 2010) is 5096 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: 'RFC5565' is defined on line 511, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 520, but no explicit reference was found in the text == Unused Reference: 'RFC3032' is defined on line 523, but no explicit reference was found in the text == Unused Reference: 'RFC5036' is defined on line 527, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-03 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force F. Brockners 3 Internet-Draft S. Gundavelli 4 Intended status: Standards Track Cisco 5 Expires: November 12, 2010 S. Speicher 6 Deutsche Telekom AG 7 D. Ward 8 Juniper Networks 9 May 11, 2010 11 Gateway Initiated Dual-Stack Lite Deployment 12 draft-softwire-gateway-init-ds-lite-00 14 Abstract 16 Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a modified approach 17 to the original Dual-Stack lite (DS-lite) applicable to certain 18 tunnel-based access architectures. GI-DS-lite extends existing 19 access tunnels beyond the access gateway to an IPv4-IPv4 NAT using 20 softwires with an embedded context identifier, that uniquely 21 identifies the end-system the tunneled packets belong to. The access 22 gateway determines which portion of the traffic requires NAT using 23 local policies and sends/receives this portion to/from this softwire 24 tunnel. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on November 12, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Gateway Initiated DS-Lite . . . . . . . . . . . . . . . . . . 4 63 4. Protocol and related Considerations . . . . . . . . . . . . . 6 64 5. Tunnel Management and related Considerations . . . . . . . . . 7 65 6. Tunnel Modes . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 7. GI-DS-lite deployment . . . . . . . . . . . . . . . . . . . . 9 67 7.1. Connectivity establishment: Example call flow . . . . . . 9 68 7.2. GI-DS-lite applicability: Examples . . . . . . . . . . . . 10 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 74 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Overview 79 Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a variant of the 80 Dual-Stack lite (DS-lite) [I-D.ietf-softwire-dual-stack-lite], 81 applicable to network architectures which use point to point tunnels 82 between the access device and the access gateway. The access gateway 83 in these models is designed to serve large number of access devices. 84 Mobile architectures based on Mobile IPv6 [RFC3775], Proxy Mobile 85 IPv6 [RFC5213], or GTP [TS29060], or broadband architectures based on 86 PPP or point-to-point VLANs as defined by the Broadband Forum (see 87 [TR59] and [TR101]) are examples for this type of architecture. 89 The DS-lite approach leverages IPv4-in-IPv6 tunnels (or other 90 tunneling modes) for carrying the IPv4 traffic from the customer 91 network to the Address Family Transition Router (AFTR). An 92 established tunnel between the AFTR and the access device is used for 93 traffic forwarding purposes. This turns the inner IPv4 address 94 irrelevant for traffic routing and allows sharing private IPv4 95 addresses [RFC1918] between customer sites within the service 96 provider network. 98 Similar to DS-lite, GI-DS-lite enables the service provider to share 99 public IPv4 addresses among different customers by combining 100 tunneling and NAT. It allows multiple access devices behind the 101 access gateway to share the same private IPv4 address [RFC1918]. 102 Rather than initiating the tunnel right on the access device, GI-DS- 103 lite logically extends the already existing access tunnels beyond the 104 access gateway towards the IPv4-IPv4 NAT using a tunneling mechanism 105 with semantics for carrying context state related to the encapsulated 106 traffic. This approach results in supporting overlapping IPv4 107 addresses in the access network, requiring no changes to either the 108 access device, or to the access architecture. Additional tunneling 109 overhead in the access network is also omitted. If e.g., a GRE based 110 encapsulation mechanisms is chosen, it allows the network between the 111 access gateway and the NAT to be either IPv4 or IPv6 and provides the 112 operator to migrate to IPv6 in incremental steps. 114 2. Conventions 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 The following abbreviations are used within this document: 122 AFTR: Address Family Transition Router (also known as "Large Scale 123 NAT (LSN)" or "Dual-Stack lite Tunnel Concentrator", or "Carrier 124 Grade NAT"). An AFTR combines IP-in-IP tunnel termination and 125 IPv4-IPv4 NAT. 127 AD: Access Device. It is the end host, also known as the mobile 128 node in mobile architectures. 130 DS-lite: Dual-stack lite 132 GI-DS-lite: Gateway-initiated DS-lite 134 NAT: Network Address Translator 136 CID: Context Identifier 138 TID: Tunnel Identifier. It is the interface identifier of the 139 point-to-point tunnel. 141 3. Gateway Initiated DS-Lite 143 The section provides an overview of Gateway Initiated DS-Lite (GI-DS- 144 lite). Figure 1 outlines the generic deployment scenario for GI-DS- 145 lite. This generic scenario can be mapped to multiple different 146 access architectures, some of which are described in Section 7. 148 In Figure 1, access devices (AD-1 and AD-2) are connected to the 149 Gateway using some form of tunnel technology and the same is used for 150 carrying IPv4 (and optionally IPv6) traffic of the access device. 151 These access devices may also be connected to the Gateway over point- 152 to-point links. The details on how the network delivers the IPv4 153 address configuration to the access devices are specific to the 154 access architecture and are outside the scope of this document. With 155 GI-DS-lite, Gateway and AFTR are connected by a softwire tunnel. A 156 Context-Identifier (CID) is used to multiplex flows associated with 157 the individual access devices onto the softwire tunnel. Local 158 policies at the Gateway determine which part of the traffic received 159 from an access device is tunneled to the AFTR. The combination of 160 CID and softwire tunnel serves as common context between Gateway and 161 AFTR to identify flows associated with an access device. The CID is 162 a 32-bit wide identifier and is assigned by the gateway. It is 163 retrieved either from a local or remote (e.g. AAA) repository. The 164 CID ensures a unique identification (potentially along with other 165 traffic identifiers such as e.g. interface, VLAN, port, etc.) of 166 traffic flows at the Gateway and AFTR. The embodiment of the CID and 167 tunnel identifier depends on the tunnel mode used and the type of the 168 network connecting Gateway and AFTR. If, for example GRE [RFC2784] 169 with "GRE Key and Sequence Number Extensions" [RFC2890] is used as 170 tunneling technology, the network connecting Gateway and AFTR could 171 be either IPv4-only, IPv6-only, or a dual-stack IP network. The CID 172 would be carried within the GRE-key field. See Section 6 for details 173 on different tunnel modes supported with GI-DS-lite. 175 Access Device: AD-1 176 Context Id: CID-1 177 NAT Mappings: 178 IPv4: a.b.c.d +---+ (CID-1, TCP port1 <-> 179 +------+ Tunnel (TID-1) | | e.f.g.h, TCP port2) 180 | AD-1 |=================| G | +---+ 181 +------+ | A | | A | 182 | T | Softwire tunnel | F | 183 | E |==========================| T | 184 IPv4: a.b.c.d | W | (e.g. IPv4-over-GRE | R | 185 +------+ | A | over IPv4 or IPv6) +---+ 186 | AD-2 |=================| Y | 187 +------+ Tunnel (TID-2) | | (CID-2, TCP port3 <-> 188 | | e.f.g.h, TCP port4) 189 +---+ 191 Access Device: AD-2 192 Context Id: CID-2 194 Figure 1: Gateway-initiated dual-stack lite reference architecture 196 The AFTR combines tunnel termination and IPv4-IPv4 NAT. The outer/ 197 external IPv4 address of a NAT-binding at the AFTR is either assigned 198 autonomously by the AFTR from a local address pool, configured on a 199 per-binding basis (either by a remote control entity through a NAT 200 control protocol or through manual configuration), or derived from 201 the CID (e.g., the 32-bit CID could be mapped 1:1 to an external 202 IPv4-address). A simple example of a translation table at the AFTR 203 is shown in Figure 2. The choice of the appropriate translation 204 scheme for a traffic flow can take parameters such as destination IP- 205 address, incoming interface, etc. into account. The IP-address of 206 the AFTR, which, depending on the transport network between the 207 Gateway and the AFTR, will either be an IPv6 or an IPv4 address, is 208 configured on the Gateway. A variety of methods, such as out-of-band 209 mechanisms, or manual configuration apply. The AFTR can, but does 210 not have to be co-located with the Gateway. 212 +============================+=========================+ 213 | Context-Id/IPv4/Port | Public IPv4/Port | 214 +============================+=========================+ 215 | CID-1/a.b.c.d/TCP port1 | e.f.g.h/TCP port2 | 216 | | | 217 | CID-2/a.b.c.d/TCP port3 | e.f.g.h/TCP port4 | 218 +----------------------------+-------------------------+ 220 Figure 2: Example translation table on the AFTR 222 4. Protocol and related Considerations 224 o The NAT binding entry maintained at the AFTR, which reflects an 225 active flow between an access device inside the network and a node 226 in the Internet, needs to be extended to include two other 227 parameters, the CID and the identifier of the softwire tunnel. 229 o When creating an IPv4 to IPv4 NAT binding for an IPv4 packet flow 230 received from the Gateway over the softwire tunnel, the AFTR will 231 associate the CID with that NAT binding. It will use the 232 combination of CID and tunnel identifier as the unique identifier 233 and will store it in the NAT binding entry. 235 o When forwarding a packet to the access device, the AFTR will 236 obtain the CID from the NAT binding associated with that flow. 237 E.g., in case of GRE-encapsulation, it will add the CID to the GRE 238 Key and Sequence number extension of the GRE header and tunnel it 239 to the Gateway. 241 o On receiving any packet from the tunnel, the AFTR will obtain the 242 CID from the incoming packet and will use it for performing the 243 NAT binding look up and for performing the packet translation 244 before forwarding the packet. 246 o The Gateway, on receiving any IPv4 packet from the access device 247 will lookup the CID for that access device. In case of GRE 248 encapsulation it will for example add the CID to the GRE Key and 249 Sequence number extension of the GRE header and tunnel it to the 250 AFTR. 252 o On receiving any packet from the tunnel, the Gateway will obtain 253 the CID from the packet and will use it for making the forwarding 254 decision. There will be an association between the CID and the 255 forwarding state. 257 o When encapsulating and IPv4 packet, Gateway and AFTR can its 258 Diffserv Codepoint (DSCP) to derive the DSCP (or MPLS Traffic- 259 Class Field in case of MPLS) of the softwire tunnel. 261 5. Tunnel Management and related Considerations 263 The following are the considerations related to the operational 264 management of the tunnel between AFTR and Gateway. 266 o The tunnel between the Gateway and the AFTR is created at system 267 startup time and stays up active all time. Deployment dependent, 268 Gateway and AFTR can employ OAM mechanisms such as ICMP, BFD 269 [I-D.ietf-bfd-base], or LSP ping [RFC4379] for tunnel health 270 management and corresponding protection stretegies. 272 o The tunnel peers may be provisioned to perform policy enforcement, 273 such as for determining the protocol-type or overall portion of 274 traffic that gets tunneled, or for any other quality of service 275 related settings. The specific details on how this is achieved or 276 the types of policies that can be applied are outside the scope 277 for this document. 279 o The tunnel peers must have a proper understanding of the path MTU 280 value. This can be statically configured at the tunnel creation 281 time. 283 o A Gateway and an AFTR can have multiple softwire tunnels 284 established between them (e.g. to separate address domains, 285 provide for load-sharing etc.). 287 6. Tunnel Modes 289 Deployment and requirements dependent, different tunnel technologies 290 apply for connecting Gateway and AFTR. GRE encapsulation with GRE- 291 key extensions, MPLS VPNs, or plain IP-in-IP encapsulation can be 292 used. Tunnel identification and Context-ID depend on the tunneling 293 technology employed: 295 o GRE with GRE-key extensions: Tunnel identification is supplied by 296 the endpoints of the GRE tunnel. The GRE-key serves as CID. 298 o MPLS VPN: Tunnel identification is supplied by the VPN identifier 299 of the MPLS VPN. The IPv4-address serves as CID. The IPv4- 300 address within a VPN has to be unique. 302 o Plain IP-in-IP: Tunnel identification is supplied by the endpoints 303 of the IP-in-IP tunnel. The inner IPv4-address serves as CID. 304 The IPv4-address has to be unique. 306 Figure 3 gives an overview of the different tunnel modes as they 307 apply to different deployment scenarios. "x" indicates that a certain 308 deployment scenario is supported. The following abbreviations are 309 used: 311 o IPv4 address 313 * "up": Deployments with "unique private IPv4 addresses" assigned 314 to the access devices are supported. 316 * "op": Deployments with "overlapping private IPv4 addresses" 317 assigned to the access devices are supported. 319 * "nm": Deployments with "non-meaningful/dummy but unique IPv4 320 addresses" assigned to the access devices are supported. 322 * "s": Deployments where all access devices are assigned the same 323 IPv4 address are supported. 325 o Network-type 327 * "v4": Gateway and AFTR are connected by an IPv4-only network 329 * "v6": Gateway and AFTR are connected by an IPv6-only network 331 * "v4v6": Gateway and AFTR are connected by a dual stack network, 332 supporting IPv4 and IPv4. 334 * "MPLS": Gateway and AFTR are connected by a MPLS network 336 +==================+==================+=======================+ 337 | | IPv4 address | Network-type | 338 | Tunnel mode +----+----+----+---+----+----+------+------+ 339 | | up | op | nm | s | v4 | v6 | v4v6 | MPLS | 340 +==================+====+====+====+===+====+====+======+======+ 341 | GRE with GRE-key | x | x | x | x | x | x | x | | 342 | MPLS VPN | x | x | x | | | | | x | 343 | Plain IP-in-IP | x | | x | | x | x | x | | 344 +==================+====+====+====+===+====+====+======+======+ 346 Figure 3: Tunnel modes and their applicability 348 7. GI-DS-lite deployment 350 7.1. Connectivity establishment: Example call flow 352 Figure 4 shows an example call flow - linking access tunnel 353 establishment on the Gateway with softwire tunneling to the AFTR. 354 This simple example assumes that traffic from the AD uses a single 355 access tunnel and that the Gateway will use local polices to decide 356 which portion of the traffic received over this access tunnel needs 357 to be forwarded to the AFTR. 359 AD Gateway AAA/Policy AFTR 360 | | | | 361 |----(1)-------->| | | 362 | (2)<-------------->| | 363 | (3) | | 364 | |<------(4)------------------->| 365 | (5) | | 366 |<---(6)-------->| | | 367 | | | | 369 Figure 4: Example call flow for session establishment 371 1. Gateway receives a request to create an access tunnel endpoint. 373 2. The Gateway authenticates and authorizes the access tunnel. 374 Based on local policy or through interaction with the AAA/Policy 375 system the Gateway recognizes that IPv4 service should be 376 provided using GI-DS-lite. 378 3. The Gateway creates an access tunnel endpoint. The access tunnel 379 links AD and Gateway and is uniquely identified by Tunnel 380 Identifier (TID) on the Gateway. 382 4. (Optional): The Gateway and the AFTR establish a control session 383 between each other. This session can for example be used to 384 exchange accounting or NAT-configuration information. Accounting 385 information could be supplied to the Gateway, AAA/Policy, or 386 other network entities which require information about the 387 externally visible address/port pairs of a particular access 388 device. The Diameter NAT Control Application (see 389 [I-D.draft-ietf-dime-nat-control] could for example be used for 390 this purpose. 392 5. The Gateway allocates a unique CID and associates those flows 393 received from the access tunnel (identified by the TID) that need 394 to be tunneled towards the AFTR with the softwire linking Gateway 395 and AFTR. Local forwarding policy on the Gateway determines 396 which traffic will need to be tunneled towards the AFTR. 398 6. Gateway and AD complete the access tunnel establishment 399 (depending on the procedures and mechanisms of the corresponding 400 access network architecture this step can include the assignment 401 of an IPv4 address to the AD). 403 7.2. GI-DS-lite applicability: Examples 405 The section outlines deployment examples of the generic GI-DS-lite 406 architecture described in Section 3. 408 o Mobile IP based access architectures: In a MIPv6 [RFC5555] based 409 network scenario, the Mobile IPv6 home agent will implement the 410 GI-DS-lite Gateway function along with the dual-stack Mobile IPv6 411 functionality. 413 o Proxy Mobile IP based access architectures: In a PMIPv6 [RFC5213] 414 scenario the local mobility anchor (LMA) will implement the GI-DS- 415 lite Gateway function along with the PMIPv6 IPv4 support 416 functionality. 418 o GTP based access architectures: 3GPP TS 23.401 [TS23401] and 3GPP 419 TS 23.060 [TS23060] define mobile access architectures using GTP. 420 For GI-DS-lite, the PDN-Gateway/GGSN will also assume the Gateway 421 function. 423 o Fixed WiMAX architecture: If GI-DS-lite is applied to fixed WiMAX, 424 the ASN-Gateway will implement the GI-DS-lite Gateway function. 426 o Mobile WiMAX: If GI-DS-lite is applied to mobile WiMAX, the home 427 agent will implement the Gateway function. 429 o PPP-based broadband access architectures: If GI-DS-lite is applied 430 to PPP-based access architectures the Broadband Remote Access 431 Server (BRAS) or Broadband Network Gateway (BNG) will implement 432 the GI-DS-lite Gateway function. 434 o In broadband access architectures using per-subscriber VLANs the 435 BNG will implement the GI-DS-lite Gateway function. 437 8. Acknowledgements 439 The authors would like to acknowledge the discussions on this topic 440 with Mark Grayson, Jay Iyer, Kent Leung, Vojislav Vucetic, Flemming 441 Andreasen, Dan Wing, Jouni Korhonen, Teemu Savolainen, Parviz Yegani, 442 Farooq Bari, Mohamed Boucadair, Vinod Pandey, Jari Arkko and Eric 443 Voit. 445 9. IANA Considerations 447 This document includes no request to IANA. 449 All drafts are required to have an IANA considerations section (see 450 the update of RFC 2434 [RFC5226] for a guide). If the draft does not 451 require IANA to do anything, the section contains an explicit 452 statement that this is the case (as above). If there are no 453 requirements for IANA, the section will be removed during conversion 454 into an RFC by the RFC Editor. 456 10. Security Considerations 458 All the security considerations from GTP [TS29060], Mobile IPv6 459 [RFC3775], Proxy Mobile IPv6 [RFC5213], and Dual-Stack lite 460 [I-D.ietf-softwire-dual-stack-lite] apply to this specification as 461 well. 463 11. References 465 11.1. Normative References 467 [I-D.ietf-bfd-base] 468 Katz, D. and D. Ward, "Bidirectional Forwarding 469 Detection", draft-ietf-bfd-base-11 (work in progress), 470 January 2010. 472 [I-D.ietf-softwire-dual-stack-lite] 473 Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee, 474 Y., and R. Bush, "Dual-stack lite broadband deployments 475 post IPv4 exhaustion", 476 draft-ietf-softwire-dual-stack-lite-03 (work in progress), 477 February 2010. 479 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 480 E. Lear, "Address Allocation for Private Internets", 481 BCP 5, RFC 1918, February 1996. 483 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 484 Requirement Levels", BCP 14, RFC 2119, March 1997. 486 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 488 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 489 March 2000. 491 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 492 RFC 2890, September 2000. 494 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 495 in IPv6", RFC 3775, June 2004. 497 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 498 Label Switched (MPLS) Data Plane Failures", RFC 4379, 499 February 2006. 501 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 502 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 504 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 505 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 506 May 2008. 508 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 509 Routers", RFC 5555, June 2009. 511 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 512 Framework", RFC 5565, June 2009. 514 11.2. Informative References 516 [I-D.draft-ietf-dime-nat-control] 517 Brockners, F., Bhandari, S., Singh, V., and V. Fajardo, 518 "Diameter NAT Control Application", August 2009. 520 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 521 Label Switching Architecture", RFC 3031, January 2001. 523 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 524 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 525 Encoding", RFC 3032, January 2001. 527 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 528 Specification", RFC 5036, October 2007. 530 [TR101] Broadband Forum, "TR-101: Migration to Ethernet-Based DSL 531 Aggregation", April 2006. 533 [TR59] Broadband Forum, "TR-059: DSL Evolution - Architecture 534 Requirements for the Support of QoS-Enabled IP Services", 535 September 2003. 537 [TS23060] "3rd Generation Partnership Project; Technical 538 Specification Group Services and System Aspects; General 539 Packet Radio Service (GPRS); Service description; Stage 540 2.", 2009. 542 [TS23401] "3rd Generation Partnership Project; Technical 543 Specification Group Services and System Aspects; General 544 Packet Radio Service (GPRS) enhancements for Evolved 545 Universal Terrestrial Radio Access Network (E-UTRAN) 546 access.", 2009. 548 [TS29060] "3rd Generation Partnership Project; Technical 549 Specification Group Core Network and Terminals; General 550 Packet Radio Service (GPRS); GPRS Tunnelling Protocol 551 (GTP), V9.1.0", 2009. 553 Authors' Addresses 555 Frank Brockners 556 Cisco 557 Hansaallee 249, 3rd Floor 558 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 559 Germany 561 Email: fbrockne@cisco.com 563 Sri Gundavelli 564 Cisco 565 170 West Tasman Drive 566 SAN JOSE, CA 95134 567 USA 569 Email: sgundave@cisco.com 571 Sebastian Speicher 572 Deutsche Telekom AG 573 Landgrabenweg 151 574 BONN, NORDRHEIN-WESTFALEN 53277 575 Germany 577 Email: sebastian.speicher@telekom.de 578 David Ward 579 Juniper Networks 580 1194 N. Mathilda Ave. 581 Sunnyvale, California 94089-1206 582 USA 584 Email: dward@juniper.net