idnits 2.17.1 draft-gundavelli-softwire-gateway-init-ds-lite-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (March 8, 2010) is 5160 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) == 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 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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: September 9, 2010 S. Speicher 6 Deutsche Telekom AG 7 D. Ward 8 Juniper Networks 9 March 8, 2010 11 Gateway Initiated Dual-Stack Lite Deployment 12 draft-gundavelli-softwire-gateway-init-ds-lite-03 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 to IETF 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), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 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 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on September 9, 2010. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 Table of Contents 66 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Gateway Initiated DS-Lite . . . . . . . . . . . . . . . . . . 4 69 4. Protocol and related Considerations . . . . . . . . . . . . . 6 70 5. Tunnel Management and related Considerations . . . . . . . . . 7 71 6. Tunnel Modes . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 7. GI-DS-lite deployment . . . . . . . . . . . . . . . . . . . . 9 73 7.1. Connectivity establishment: Example call flow . . . . . . 9 74 7.2. GI-DS-lite applicability: Examples . . . . . . . . . . . . 10 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 80 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Overview 85 Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a variant of the 86 Dual-Stack lite (DS-lite) [I-D.ietf-softwire-dual-stack-lite], 87 applicable to network architectures which use point to point tunnels 88 between the access device and the access gateway. The access gateway 89 in these models is designed to serve large number of access devices. 90 Mobile architectures based on Mobile IPv6 [RFC3775], Proxy Mobile 91 IPv6 [RFC5213], or GTP [TS29060], or broadband architectures based on 92 PPP or point-to-point VLANs as defined by the Broadband Forum (see 93 [TR59] and [TR101]) are examples for this type of architecture. 95 The DS-lite approach leverages IPv4-in-IPv6 tunnels (or other 96 tunneling modes) for carrying the IPv4 traffic from the customer 97 network to the Address Family Transition Router (AFTR). An 98 established tunnel between the AFTR and the access device is used for 99 traffic forwarding purposes. This turns the inner IPv4 address 100 irrelevant for traffic routing and allows sharing private IPv4 101 addresses [RFC1918] between customer sites within the service 102 provider network. 104 Similar to DS-lite, GI-DS-lite enables the service provider to share 105 public IPv4 addresses among different customers by combining 106 tunneling and NAT. It allows multiple access devices behind the 107 access gateway to share the same private IPv4 address [RFC1918]. 108 Rather than initiating the tunnel right on the access device, GI-DS- 109 lite logically extends the already existing access tunnels beyond the 110 access gateway towards the IPv4-IPv4 NAT using a tunneling mechanism 111 with semantics for carrying context state related to the encapsulated 112 traffic. This approach results in supporting overlapping IPv4 113 addresses in the access network, requiring no changes to either the 114 access device, or to the access architecture. Additional tunneling 115 overhead in the access network is also omitted. If e.g., a GRE based 116 encapsulation mechanisms is chosen, it allows the network between the 117 access gateway and the NAT to be either IPv4 or IPv6 and provides the 118 operator to migrate to IPv6 in incremental steps. 120 2. Conventions 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 The following abbreviations are used within this document: 128 AFTR: Address Family Transition Router (also known as "Large Scale 129 NAT (LSN)" or "Dual-Stack lite Tunnel Concentrator", or "Carrier 130 Grade NAT"). An AFTR combines IP-in-IP tunnel termination and 131 IPv4-IPv4 NAT. 133 AD: Access Device. It is the end host, also known as the mobile 134 node in mobile architectures. 136 DS-lite: Dual-stack lite 138 GI-DS-lite: Gateway-initiated DS-lite 140 NAT: Network Address Translator 142 CID: Context Identifier 144 TID: Tunnel Identifier. It is the interface identifier of the 145 point-to-point tunnel. 147 3. Gateway Initiated DS-Lite 149 The section provides an overview of Gateway Initiated DS-Lite (GI-DS- 150 lite). Figure 1 outlines the generic deployment scenario for GI-DS- 151 lite. This generic scenario can be mapped to multiple different 152 access architectures, some of which are described in Section 7. 154 In Figure 1, access devices (AD-1 and AD-2) are connected to the 155 Gateway using some form of tunnel technology and the same is used for 156 carrying IPv4 (and optionally IPv6) traffic of the access device. 157 These access devices may also be connected to the Gateway over point- 158 to-point links. The details on how the network delivers the IPv4 159 address configuration to the access devices are specific to the 160 access architecture and are outside the scope of this document. With 161 GI-DS-lite, Gateway and AFTR are connected by a softwire tunnel. A 162 Context-Identifier (CID) is used to multiplex flows associated with 163 the individual access devices onto the softwire tunnel. Local 164 policies at the Gateway determine which part of the traffic received 165 from an access device is tunneled to the AFTR. The combination of 166 CID and softwire tunnel serves as common context between Gateway and 167 AFTR to identify flows associated with an access device. The CID is 168 a 32-bit wide identifier and is assigned by the gateway. It is 169 retrieved either from a local or remote (e.g. AAA) repository. The 170 CID ensures a unique identification (potentially along with other 171 traffic identifiers such as e.g. interface, VLAN, port, etc.) of 172 traffic flows at the Gateway and AFTR. The embodiment of the CID and 173 tunnel identifier depends on the tunnel mode used and the type of the 174 network connecting Gateway and AFTR. If, for example GRE [RFC2784] 175 with "GRE Key and Sequence Number Extensions" [RFC2890] is used as 176 tunneling technology, the network connecting Gateway and AFTR could 177 be either IPv4-only, IPv6-only, or a dual-stack IP network. The CID 178 would be carried within the GRE-key field. See Section 6 for details 179 on different tunnel modes supported with GI-DS-lite. 181 Access Device: AD-1 182 Context Id: CID-1 183 NAT Mappings: 184 IPv4: a.b.c.d +---+ (CID-1, TCP port1 <-> 185 +------+ Tunnel (TID-1) | | e.f.g.h, TCP port2) 186 | AD-1 |=================| G | +---+ 187 +------+ | A | | A | 188 | T | Softwire tunnel | F | 189 | E |==========================| T | 190 IPv4: a.b.c.d | W | (e.g. IPv4-over-GRE | R | 191 +------+ | A | over IPv4 or IPv6) +---+ 192 | AD-2 |=================| Y | 193 +------+ Tunnel (TID-2) | | (CID-2, TCP port3 <-> 194 | | e.f.g.h, TCP port4) 195 +---+ 197 Access Device: AD-2 198 Context Id: CID-2 200 Figure 1: Gateway-initiated dual-stack lite reference architecture 202 The AFTR combines tunnel termination and IPv4-IPv4 NAT. The outer/ 203 external IPv4 address of a NAT-binding at the AFTR is either assigned 204 autonomously by the AFTR from a local address pool, configured on a 205 per-binding basis (either by a remote control entity through a NAT 206 control protocol or through manual configuration), or derived from 207 the CID (e.g., the 32-bit CID could be mapped 1:1 to an external 208 IPv4-address). A simple example of a translation table at the AFTR 209 is shown in Figure 2. The choice of the appropriate translation 210 scheme for a traffic flow can take parameters such as destination IP- 211 address, incoming interface, etc. into account. The IP-address of 212 the AFTR, which, depending on the transport network between the 213 Gateway and the AFTR, will either be an IPv6 or an IPv4 address, is 214 configured on the Gateway. A variety of methods, such as out-of-band 215 mechanisms, or manual configuration apply. The AFTR can, but does 216 not have to be co-located with the Gateway. 218 +============================+=========================+ 219 | Context-Id/IPv4/Port | Public IPv4/Port | 220 +============================+=========================+ 221 | CID-1/a.b.c.d/TCP port1 | e.f.g.h/TCP port2 | 222 | | | 223 | CID-2/a.b.c.d/TCP port3 | e.f.g.h/TCP port4 | 224 +----------------------------+-------------------------+ 226 Figure 2: Example translation table on the AFTR 228 4. Protocol and related Considerations 230 o The NAT binding entry maintained at the AFTR, which reflects an 231 active flow between an access device inside the network and a node 232 in the Internet, needs to be extended to include two other 233 parameters, the CID and the identifier of the softwire tunnel. 235 o When creating an IPv4 to IPv4 NAT binding for an IPv4 packet flow 236 received from the Gateway over the softwire tunnel, the AFTR will 237 associate the CID with that NAT binding. It will use the 238 combination of CID and tunnel identifier as the unique identifier 239 and will store it in the NAT binding entry. 241 o When forwarding a packet to the access device, the AFTR will 242 obtain the CID from the NAT binding associated with that flow. 243 E.g., in case of GRE-encapsulation, it will add the CID to the GRE 244 Key and Sequence number extension of the GRE header and tunnel it 245 to the Gateway. 247 o On receiving any packet from the tunnel, the AFTR will obtain the 248 CID from the incoming packet and will use it for performing the 249 NAT binding look up and for performing the packet translation 250 before forwarding the packet. 252 o The Gateway, on receiving any IPv4 packet from the access device 253 will lookup the CID for that access device. In case of GRE 254 encapsulation it will for example add the CID to the GRE Key and 255 Sequence number extension of the GRE header and tunnel it to the 256 AFTR. 258 o On receiving any packet from the tunnel, the Gateway will obtain 259 the CID from the packet and will use it for making the forwarding 260 decision. There will be an association between the CID and the 261 forwarding state. 263 o When encapsulating and IPv4 packet, Gateway and AFTR can its 264 Diffserv Codepoint (DSCP) to derive the DSCP (or MPLS Traffic- 265 Class Field in case of MPLS) of the softwire tunnel. 267 5. Tunnel Management and related Considerations 269 The following are the considerations related to the operational 270 management of the tunnel between AFTR and Gateway. 272 o The tunnel between the Gateway and the AFTR is created at system 273 startup time and stays up active all time. Deployment dependent, 274 Gateway and AFTR can employ OAM mechanisms such as ICMP, BFD 275 [I-D.ietf-bfd-base], or LSP ping [RFC4379] for tunnel health 276 management and corresponding protection stretegies. 278 o The tunnel peers may be provisioned to perform policy enforcement, 279 such as for determining the protocol-type or overall portion of 280 traffic that gets tunneled, or for any other quality of service 281 related settings. The specific details on how this is achieved or 282 the types of policies that can be applied are outside the scope 283 for this document. 285 o The tunnel peers must have a proper understanding of the path MTU 286 value. This can be statically configured at the tunnel creation 287 time. 289 o A Gateway and an AFTR can have multiple softwire tunnels 290 established between them (e.g. to separate address domains, 291 provide for load-sharing etc.). 293 6. Tunnel Modes 295 Deployment and requirements dependent, different tunnel technologies 296 apply for connecting Gateway and AFTR. GRE encapsulation with GRE- 297 key extensions, MPLS VPNs, or plain IP-in-IP encapsulation can be 298 used. Tunnel identification and Context-ID depend on the tunneling 299 technology employed: 301 o GRE with GRE-key extensions: Tunnel identification is supplied by 302 the endpoints of the GRE tunnel. The GRE-key serves as CID. 304 o MPLS VPN: Tunnel identification is supplied by the VPN identifier 305 of the MPLS VPN. The IPv4-address serves as CID. The IPv4- 306 address within a VPN has to be unique. 308 o Plain IP-in-IP: Tunnel identification is supplied by the endpoints 309 of the IP-in-IP tunnel. The inner IPv4-address serves as CID. 310 The IPv4-address has to be unique. 312 Figure 3 gives an overview of the different tunnel modes as they 313 apply to different deployment scenarios. "x" indicates that a certain 314 deployment scenario is supported. The following abbreviations are 315 used: 317 o IPv4 address 319 * "up": Deployments with "unique private IPv4 addresses" assigned 320 to the access devices are supported. 322 * "op": Deployments with "overlapping private IPv4 addresses" 323 assigned to the access devices are supported. 325 * "nm": Deployments with "non-meaningful/dummy but unique IPv4 326 addresses" assigned to the access devices are supported. 328 * "s": Deployments where all access devices are assigned the same 329 IPv4 address are supported. 331 o Network-type 333 * "v4": Gateway and AFTR are connected by an IPv4-only network 335 * "v6": Gateway and AFTR are connected by an IPv6-only network 337 * "v4v6": Gateway and AFTR are connected by a dual stack network, 338 supporting IPv4 and IPv4. 340 * "MPLS": Gateway and AFTR are connected by a MPLS network 342 +==================+==================+=======================+ 343 | | IPv4 address | Network-type | 344 | Tunnel mode +----+----+----+---+----+----+------+------+ 345 | | up | op | nm | s | v4 | v6 | v4v6 | MPLS | 346 +==================+====+====+====+===+====+====+======+======+ 347 | GRE with GRE-key | x | x | x | x | x | x | x | | 348 | MPLS VPN | x | x | x | | | | | x | 349 | Plain IP-in-IP | x | | x | | x | x | x | | 350 +==================+====+====+====+===+====+====+======+======+ 352 Figure 3: Tunnel modes and their applicability 354 7. GI-DS-lite deployment 356 7.1. Connectivity establishment: Example call flow 358 Figure 4 shows an example call flow - linking access tunnel 359 establishment on the Gateway with softwire tunneling to the AFTR. 360 This simple example assumes that traffic from the AD uses a single 361 access tunnel and that the Gateway will use local polices to decide 362 which portion of the traffic received over this access tunnel needs 363 to be forwarded to the AFTR. 365 AD Gateway AAA/Policy AFTR 366 | | | | 367 |----(1)-------->| | | 368 | (2)<-------------->| | 369 | (3) | | 370 | |<------(4)------------------->| 371 | (5) | | 372 |<---(6)-------->| | | 373 | | | | 375 Figure 4: Example call flow for session establishment 377 1. Gateway receives a request to create an access tunnel endpoint. 379 2. The Gateway authenticates and authorizes the access tunnel. 380 Based on local policy or through interaction with the AAA/Policy 381 system the Gateway recognizes that IPv4 service should be 382 provided using GI-DS-lite. 384 3. The Gateway creates an access tunnel endpoint. The access tunnel 385 links AD and Gateway and is uniquely identified by Tunnel 386 Identifier (TID) on the Gateway. 388 4. (Optional): The Gateway and the AFTR establish a control session 389 between each other. This session can for example be used to 390 exchange accounting or NAT-configuration information. Accounting 391 information could be supplied to the Gateway, AAA/Policy, or 392 other network entities which require information about the 393 externally visible address/port pairs of a particular access 394 device. The Diameter NAT Control Application (see 395 [I-D.draft-ietf-dime-nat-control] could for example be used for 396 this purpose. 398 5. The Gateway allocates a unique CID and associates those flows 399 received from the access tunnel (identified by the TID) that need 400 to be tunneled towards the AFTR with the softwire linking Gateway 401 and AFTR. Local forwarding policy on the Gateway determines 402 which traffic will need to be tunneled towards the AFTR. 404 6. Gateway and AD complete the access tunnel establishment 405 (depending on the procedures and mechanisms of the corresponding 406 access network architecture this step can include the assignment 407 of an IPv4 address to the AD). 409 7.2. GI-DS-lite applicability: Examples 411 The section outlines deployment examples of the generic GI-DS-lite 412 architecture described in Section 3. 414 o Mobile IP based access architectures: In a MIPv6 [RFC5555] based 415 network scenario, the Mobile IPv6 home agent will implement the 416 GI-DS-lite Gateway function along with the dual-stack Mobile IPv6 417 functionality. 419 o Proxy Mobile IP based access architectures: In a PMIPv6 [RFC5213] 420 scenario the local mobility anchor (LMA) will implement the GI-DS- 421 lite Gateway function along with the PMIPv6 IPv4 support 422 functionality. 424 o GTP based access architectures: 3GPP TS 23.401 [TS23401] and 3GPP 425 TS 23.060 [TS23060] define mobile access architectures using GTP. 426 For GI-DS-lite, the PDN-Gateway/GGSN will also assume the Gateway 427 function. 429 o Fixed WiMAX architecture: If GI-DS-lite is applied to fixed WiMAX, 430 the ASN-Gateway will implement the GI-DS-lite Gateway function. 432 o Mobile WiMAX: If GI-DS-lite is applied to mobile WiMAX, the home 433 agent will implement the Gateway function. 435 o PPP-based broadband access architectures: If GI-DS-lite is applied 436 to PPP-based access architectures the Broadband Remote Access 437 Server (BRAS) or Broadband Network Gateway (BNG) will implement 438 the GI-DS-lite Gateway function. 440 o In broadband access architectures using per-subscriber VLANs the 441 BNG will implement the GI-DS-lite Gateway function. 443 8. Acknowledgements 445 The authors would like to acknowledge the discussions on this topic 446 with Mark Grayson, Jay Iyer, Kent Leung, Vojislav Vucetic, Flemming 447 Andreasen, Dan Wing, Jouni Korhonen, Teemu Savolainen, Parviz Yegani, 448 Farooq Bari, Mohamed Boucadair, Vinod Pandey, Jari Arkko and Eric 449 Voit. 451 9. IANA Considerations 453 This document includes no request to IANA. 455 All drafts are required to have an IANA considerations section (see 456 the update of RFC 2434 [RFC5226] for a guide). If the draft does not 457 require IANA to do anything, the section contains an explicit 458 statement that this is the case (as above). If there are no 459 requirements for IANA, the section will be removed during conversion 460 into an RFC by the RFC Editor. 462 10. Security Considerations 464 All the security considerations from GTP [TS29060], Mobile IPv6 465 [RFC3775], Proxy Mobile IPv6 [RFC5213], and Dual-Stack lite 466 [I-D.ietf-softwire-dual-stack-lite] apply to this specification as 467 well. 469 11. References 471 11.1. Normative References 473 [I-D.ietf-softwire-dual-stack-lite] 474 Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee, 475 Y., and R. Bush, "Dual-stack lite broadband deployments 476 post IPv4 exhaustion", 477 draft-ietf-softwire-dual-stack-lite-03 (work in progress), 478 February 2010. 480 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 481 E. Lear, "Address Allocation for Private Internets", 482 BCP 5, RFC 1918, February 1996. 484 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 485 Requirement Levels", BCP 14, RFC 2119, March 1997. 487 [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 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 498 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 500 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 501 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 502 May 2008. 504 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 505 Routers", RFC 5555, June 2009. 507 11.2. Informative References 509 [I-D.draft-ietf-dime-nat-control] 510 Brockners, F., Bhandari, S., Singh, V., and V. Fajardo, 511 "Diameter NAT Control Application", August 2009. 513 [I-D.ietf-bfd-base] 514 Katz, D. and D. Ward, "Bidirectional Forwarding 515 Detection", draft-ietf-bfd-base-11 (work in progress), 516 January 2010. 518 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 519 Label Switched (MPLS) Data Plane Failures", RFC 4379, 520 February 2006. 522 [TR101] Broadband Forum, "TR-101: Migration to Ethernet-Based DSL 523 Aggregation", April 2006. 525 [TR59] Broadband Forum, "TR-059: DSL Evolution - Architecture 526 Requirements for the Support of QoS-Enabled IP Services", 527 September 2003. 529 [TS23060] "3rd Generation Partnership Project; Technical 530 Specification Group Services and System Aspects; General 531 Packet Radio Service (GPRS); Service description; Stage 532 2.", 2009. 534 [TS23401] "3rd Generation Partnership Project; Technical 535 Specification Group Services and System Aspects; General 536 Packet Radio Service (GPRS) enhancements for Evolved 537 Universal Terrestrial Radio Access Network (E-UTRAN) 538 access.", 2009. 540 [TS29060] "3rd Generation Partnership Project; Technical 541 Specification Group Core Network and Terminals; General 542 Packet Radio Service (GPRS); GPRS Tunnelling Protocol 543 (GTP), V9.1.0", 2009. 545 Authors' Addresses 547 Frank Brockners 548 Cisco 549 Hansaallee 249, 3rd Floor 550 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 551 Germany 553 Email: fbrockne@cisco.com 555 Sri Gundavelli 556 Cisco 557 170 West Tasman Drive 558 SAN JOSE, CA 95134 559 USA 561 Email: sgundave@cisco.com 563 Sebastian Speicher 564 Deutsche Telekom AG 565 Landgrabenweg 151 566 BONN, NORDRHEIN-WESTFALEN 53277 567 Germany 569 Email: sebastian.speicher@telekom.de 571 David Ward 572 Juniper Networks 573 1194 N. Mathilda Ave. 574 Sunnyvale, California 94089-1206 575 USA 577 Email: dward@juniper.net