[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 draft-ietf-softwire-gateway-init-ds-lite

Internet Engineering Task Force                             F. Brockners
Internet-Draft                                             S. Gundavelli
Intended status: Standards Track                                   Cisco
Expires: September 9, 2010                                   S. Speicher
                                                     Deutsche Telekom AG
                                                                 D. Ward
                                                        Juniper Networks
                                                           March 8, 2010


              Gateway Initiated Dual-Stack Lite Deployment
           draft-gundavelli-softwire-gateway-init-ds-lite-03

Abstract

   Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a modified approach
   to the original Dual-Stack lite (DS-lite) applicable to certain
   tunnel-based access architectures.  GI-DS-lite extends existing
   access tunnels beyond the access gateway to an IPv4-IPv4 NAT using
   softwires with an embedded context identifier, that uniquely
   identifies the end-system the tunneled packets belong to.  The access
   gateway determines which portion of the traffic requires NAT using
   local policies and sends/receives this portion to/from this softwire
   tunnel.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 9, 2010.




Brockners, et al.       Expires September 9, 2010               [Page 1]


Internet-Draft          Gateway-Initiated DS-Lite             March 2010


Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Gateway Initiated DS-Lite  . . . . . . . . . . . . . . . . . .  4
   4.  Protocol and related Considerations  . . . . . . . . . . . . .  6
   5.  Tunnel Management and related Considerations . . . . . . . . .  7
   6.  Tunnel Modes . . . . . . . . . . . . . . . . . . . . . . . . .  7
   7.  GI-DS-lite deployment  . . . . . . . . . . . . . . . . . . . .  9
     7.1.  Connectivity establishment: Example call flow  . . . . . .  9
     7.2.  GI-DS-lite applicability: Examples . . . . . . . . . . . . 10
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     11.2. Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13

















Brockners, et al.       Expires September 9, 2010               [Page 2]


Internet-Draft          Gateway-Initiated DS-Lite             March 2010


1.  Overview

   Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a variant of the
   Dual-Stack lite (DS-lite) [I-D.ietf-softwire-dual-stack-lite],
   applicable to network architectures which use point to point tunnels
   between the access device and the access gateway.  The access gateway
   in these models is designed to serve large number of access devices.
   Mobile architectures based on Mobile IPv6 [RFC3775], Proxy Mobile
   IPv6 [RFC5213], or GTP [TS29060], or broadband architectures based on
   PPP or point-to-point VLANs as defined by the Broadband Forum (see
   [TR59] and [TR101]) are examples for this type of architecture.

   The DS-lite approach leverages IPv4-in-IPv6 tunnels (or other
   tunneling modes) for carrying the IPv4 traffic from the customer
   network to the Address Family Transition Router (AFTR).  An
   established tunnel between the AFTR and the access device is used for
   traffic forwarding purposes.  This turns the inner IPv4 address
   irrelevant for traffic routing and allows sharing private IPv4
   addresses [RFC1918] between customer sites within the service
   provider network.

   Similar to DS-lite, GI-DS-lite enables the service provider to share
   public IPv4 addresses among different customers by combining
   tunneling and NAT.  It allows multiple access devices behind the
   access gateway to share the same private IPv4 address [RFC1918].
   Rather than initiating the tunnel right on the access device, GI-DS-
   lite logically extends the already existing access tunnels beyond the
   access gateway towards the IPv4-IPv4 NAT using a tunneling mechanism
   with semantics for carrying context state related to the encapsulated
   traffic.  This approach results in supporting overlapping IPv4
   addresses in the access network, requiring no changes to either the
   access device, or to the access architecture.  Additional tunneling
   overhead in the access network is also omitted.  If e.g., a GRE based
   encapsulation mechanisms is chosen, it allows the network between the
   access gateway and the NAT to be either IPv4 or IPv6 and provides the
   operator to migrate to IPv6 in incremental steps.


2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The following abbreviations are used within this document:






Brockners, et al.       Expires September 9, 2010               [Page 3]


Internet-Draft          Gateway-Initiated DS-Lite             March 2010


      AFTR: Address Family Transition Router (also known as "Large Scale
      NAT (LSN)" or "Dual-Stack lite Tunnel Concentrator", or "Carrier
      Grade NAT").  An AFTR combines IP-in-IP tunnel termination and
      IPv4-IPv4 NAT.

      AD: Access Device.  It is the end host, also known as the mobile
      node in mobile architectures.

      DS-lite: Dual-stack lite

      GI-DS-lite: Gateway-initiated DS-lite

      NAT: Network Address Translator

      CID: Context Identifier

      TID: Tunnel Identifier.  It is the interface identifier of the
      point-to-point tunnel.


3.  Gateway Initiated DS-Lite

   The section provides an overview of Gateway Initiated DS-Lite (GI-DS-
   lite).  Figure 1 outlines the generic deployment scenario for GI-DS-
   lite.  This generic scenario can be mapped to multiple different
   access architectures, some of which are described in Section 7.

   In Figure 1, access devices (AD-1 and AD-2) are connected to the
   Gateway using some form of tunnel technology and the same is used for
   carrying IPv4 (and optionally IPv6) traffic of the access device.
   These access devices may also be connected to the Gateway over point-
   to-point links.  The details on how the network delivers the IPv4
   address configuration to the access devices are specific to the
   access architecture and are outside the scope of this document.  With
   GI-DS-lite, Gateway and AFTR are connected by a softwire tunnel.  A
   Context-Identifier (CID) is used to multiplex flows associated with
   the individual access devices onto the softwire tunnel.  Local
   policies at the Gateway determine which part of the traffic received
   from an access device is tunneled to the AFTR.  The combination of
   CID and softwire tunnel serves as common context between Gateway and
   AFTR to identify flows associated with an access device.  The CID is
   a 32-bit wide identifier and is assigned by the gateway.  It is
   retrieved either from a local or remote (e.g.  AAA) repository.  The
   CID ensures a unique identification (potentially along with other
   traffic identifiers such as e.g. interface, VLAN, port, etc.) of
   traffic flows at the Gateway and AFTR.  The embodiment of the CID and
   tunnel identifier depends on the tunnel mode used and the type of the
   network connecting Gateway and AFTR.  If, for example GRE [RFC2784]



Brockners, et al.       Expires September 9, 2010               [Page 4]


Internet-Draft          Gateway-Initiated DS-Lite             March 2010


   with "GRE Key and Sequence Number Extensions" [RFC2890] is used as
   tunneling technology, the network connecting Gateway and AFTR could
   be either IPv4-only, IPv6-only, or a dual-stack IP network.  The CID
   would be carried within the GRE-key field.  See Section 6 for details
   on different tunnel modes supported with GI-DS-lite.

                        Access Device: AD-1
                        Context Id: CID-1
                                             NAT Mappings:
      IPv4: a.b.c.d            +---+         (CID-1, TCP port1 <->
      +------+ Tunnel (TID-1)  |   |                 e.f.g.h, TCP port2)
      | AD-1 |=================| G |                          +---+
      +------+                 | A |                          | A |
                               | T |    Softwire tunnel       | F |
                               | E |==========================| T |
      IPv4: a.b.c.d            | W |  (e.g. IPv4-over-GRE     | R |
      +------+                 | A |   over IPv4 or IPv6)     +---+
      | AD-2 |=================| Y |
      +------+ Tunnel (TID-2)  |   |         (CID-2, TCP port3 <->
                               |   |                 e.f.g.h, TCP port4)
                               +---+

                        Access Device: AD-2
                        Context Id: CID-2

    Figure 1: Gateway-initiated dual-stack lite reference architecture

   The AFTR combines tunnel termination and IPv4-IPv4 NAT.  The outer/
   external IPv4 address of a NAT-binding at the AFTR is either assigned
   autonomously by the AFTR from a local address pool, configured on a
   per-binding basis (either by a remote control entity through a NAT
   control protocol or through manual configuration), or derived from
   the CID (e.g., the 32-bit CID could be mapped 1:1 to an external
   IPv4-address).  A simple example of a translation table at the AFTR
   is shown in Figure 2.  The choice of the appropriate translation
   scheme for a traffic flow can take parameters such as destination IP-
   address, incoming interface, etc. into account.  The IP-address of
   the AFTR, which, depending on the transport network between the
   Gateway and the AFTR, will either be an IPv6 or an IPv4 address, is
   configured on the Gateway.  A variety of methods, such as out-of-band
   mechanisms, or manual configuration apply.  The AFTR can, but does
   not have to be co-located with the Gateway.









Brockners, et al.       Expires September 9, 2010               [Page 5]


Internet-Draft          Gateway-Initiated DS-Lite             March 2010


          +============================+=========================+
          |  Context-Id/IPv4/Port      |    Public IPv4/Port     |
          +============================+=========================+
          |  CID-1/a.b.c.d/TCP port1   |    e.f.g.h/TCP port2    |
          |                            |                         |
          |  CID-2/a.b.c.d/TCP port3   |    e.f.g.h/TCP port4    |
          +----------------------------+-------------------------+


              Figure 2: Example translation table on the AFTR


4.  Protocol and related Considerations

   o  The NAT binding entry maintained at the AFTR, which reflects an
      active flow between an access device inside the network and a node
      in the Internet, needs to be extended to include two other
      parameters, the CID and the identifier of the softwire tunnel.

   o  When creating an IPv4 to IPv4 NAT binding for an IPv4 packet flow
      received from the Gateway over the softwire tunnel, the AFTR will
      associate the CID with that NAT binding.  It will use the
      combination of CID and tunnel identifier as the unique identifier
      and will store it in the NAT binding entry.

   o  When forwarding a packet to the access device, the AFTR will
      obtain the CID from the NAT binding associated with that flow.
      E.g., in case of GRE-encapsulation, it will add the CID to the GRE
      Key and Sequence number extension of the GRE header and tunnel it
      to the Gateway.

   o  On receiving any packet from the tunnel, the AFTR will obtain the
      CID from the incoming packet and will use it for performing the
      NAT binding look up and for performing the packet translation
      before forwarding the packet.

   o  The Gateway, on receiving any IPv4 packet from the access device
      will lookup the CID for that access device.  In case of GRE
      encapsulation it will for example add the CID to the GRE Key and
      Sequence number extension of the GRE header and tunnel it to the
      AFTR.

   o  On receiving any packet from the tunnel, the Gateway will obtain
      the CID from the packet and will use it for making the forwarding
      decision.  There will be an association between the CID and the
      forwarding state.





Brockners, et al.       Expires September 9, 2010               [Page 6]


Internet-Draft          Gateway-Initiated DS-Lite             March 2010


   o  When encapsulating and IPv4 packet, Gateway and AFTR can its
      Diffserv Codepoint (DSCP) to derive the DSCP (or MPLS Traffic-
      Class Field in case of MPLS) of the softwire tunnel.


5.  Tunnel Management and related Considerations

   The following are the considerations related to the operational
   management of the tunnel between AFTR and Gateway.

   o  The tunnel between the Gateway and the AFTR is created at system
      startup time and stays up active all time.  Deployment dependent,
      Gateway and AFTR can employ OAM mechanisms such as ICMP, BFD
      [I-D.ietf-bfd-base], or LSP ping [RFC4379] for tunnel health
      management and corresponding protection stretegies.

   o  The tunnel peers may be provisioned to perform policy enforcement,
      such as for determining the protocol-type or overall portion of
      traffic that gets tunneled, or for any other quality of service
      related settings.  The specific details on how this is achieved or
      the types of policies that can be applied are outside the scope
      for this document.

   o  The tunnel peers must have a proper understanding of the path MTU
      value.  This can be statically configured at the tunnel creation
      time.

   o  A Gateway and an AFTR can have multiple softwire tunnels
      established between them (e.g. to separate address domains,
      provide for load-sharing etc.).


6.  Tunnel Modes

   Deployment and requirements dependent, different tunnel technologies
   apply for connecting Gateway and AFTR.  GRE encapsulation with GRE-
   key extensions, MPLS VPNs, or plain IP-in-IP encapsulation can be
   used.  Tunnel identification and Context-ID depend on the tunneling
   technology employed:

   o  GRE with GRE-key extensions: Tunnel identification is supplied by
      the endpoints of the GRE tunnel.  The GRE-key serves as CID.

   o  MPLS VPN: Tunnel identification is supplied by the VPN identifier
      of the MPLS VPN.  The IPv4-address serves as CID.  The IPv4-
      address within a VPN has to be unique.





Brockners, et al.       Expires September 9, 2010               [Page 7]


Internet-Draft          Gateway-Initiated DS-Lite             March 2010


   o  Plain IP-in-IP: Tunnel identification is supplied by the endpoints
      of the IP-in-IP tunnel.  The inner IPv4-address serves as CID.
      The IPv4-address has to be unique.

   Figure 3 gives an overview of the different tunnel modes as they
   apply to different deployment scenarios. "x" indicates that a certain
   deployment scenario is supported.  The following abbreviations are
   used:

   o  IPv4 address

      *  "up": Deployments with "unique private IPv4 addresses" assigned
         to the access devices are supported.

      *  "op": Deployments with "overlapping private IPv4 addresses"
         assigned to the access devices are supported.

      *  "nm": Deployments with "non-meaningful/dummy but unique IPv4
         addresses" assigned to the access devices are supported.

      *  "s": Deployments where all access devices are assigned the same
         IPv4 address are supported.

   o  Network-type

      *  "v4": Gateway and AFTR are connected by an IPv4-only network

      *  "v6": Gateway and AFTR are connected by an IPv6-only network

      *  "v4v6": Gateway and AFTR are connected by a dual stack network,
         supporting IPv4 and IPv4.

      *  "MPLS": Gateway and AFTR are connected by a MPLS network

      +==================+==================+=======================+
      |                  | IPv4 address     |      Network-type     |
      |   Tunnel mode    +----+----+----+---+----+----+------+------+
      |                  | up | op | nm | s | v4 | v6 | v4v6 | MPLS |
      +==================+====+====+====+===+====+====+======+======+
      | GRE with GRE-key |  x |  x |  x | x |  x |  x |   x  |      |
      | MPLS VPN         |  x |  x |  x |   |    |    |      |   x  |
      | Plain IP-in-IP   |  x |    |  x |   |  x |  x |   x  |      |
      +==================+====+====+====+===+====+====+======+======+

              Figure 3: Tunnel modes and their applicability






Brockners, et al.       Expires September 9, 2010               [Page 8]


Internet-Draft          Gateway-Initiated DS-Lite             March 2010


7.  GI-DS-lite deployment

7.1.  Connectivity establishment: Example call flow

   Figure 4 shows an example call flow - linking access tunnel
   establishment on the Gateway with softwire tunneling to the AFTR.
   This simple example assumes that traffic from the AD uses a single
   access tunnel and that the Gateway will use local polices to decide
   which portion of the traffic received over this access tunnel needs
   to be forwarded to the AFTR.

             AD            Gateway         AAA/Policy       AFTR
             |                |                 |            |
             |----(1)-------->|                 |            |
             |               (2)<-------------->|            |
             |               (3)                |            |
             |                |<------(4)------------------->|
             |               (5)                |            |
             |<---(6)-------->|                 |            |
             |                |                 |            |


           Figure 4: Example call flow for session establishment

   1.  Gateway receives a request to create an access tunnel endpoint.

   2.  The Gateway authenticates and authorizes the access tunnel.
       Based on local policy or through interaction with the AAA/Policy
       system the Gateway recognizes that IPv4 service should be
       provided using GI-DS-lite.

   3.  The Gateway creates an access tunnel endpoint.  The access tunnel
       links AD and Gateway and is uniquely identified by Tunnel
       Identifier (TID) on the Gateway.

   4.  (Optional): The Gateway and the AFTR establish a control session
       between each other.  This session can for example be used to
       exchange accounting or NAT-configuration information.  Accounting
       information could be supplied to the Gateway, AAA/Policy, or
       other network entities which require information about the
       externally visible address/port pairs of a particular access
       device.  The Diameter NAT Control Application (see
       [I-D.draft-ietf-dime-nat-control] could for example be used for
       this purpose.

   5.  The Gateway allocates a unique CID and associates those flows
       received from the access tunnel (identified by the TID) that need
       to be tunneled towards the AFTR with the softwire linking Gateway



Brockners, et al.       Expires September 9, 2010               [Page 9]


Internet-Draft          Gateway-Initiated DS-Lite             March 2010


       and AFTR.  Local forwarding policy on the Gateway determines
       which traffic will need to be tunneled towards the AFTR.

   6.  Gateway and AD complete the access tunnel establishment
       (depending on the procedures and mechanisms of the corresponding
       access network architecture this step can include the assignment
       of an IPv4 address to the AD).

7.2.  GI-DS-lite applicability: Examples

   The section outlines deployment examples of the generic GI-DS-lite
   architecture described in Section 3.

   o  Mobile IP based access architectures: In a MIPv6 [RFC5555] based
      network scenario, the Mobile IPv6 home agent will implement the
      GI-DS-lite Gateway function along with the dual-stack Mobile IPv6
      functionality.

   o  Proxy Mobile IP based access architectures: In a PMIPv6 [RFC5213]
      scenario the local mobility anchor (LMA) will implement the GI-DS-
      lite Gateway function along with the PMIPv6 IPv4 support
      functionality.

   o  GTP based access architectures: 3GPP TS 23.401 [TS23401] and 3GPP
      TS 23.060 [TS23060] define mobile access architectures using GTP.
      For GI-DS-lite, the PDN-Gateway/GGSN will also assume the Gateway
      function.

   o  Fixed WiMAX architecture: If GI-DS-lite is applied to fixed WiMAX,
      the ASN-Gateway will implement the GI-DS-lite Gateway function.

   o  Mobile WiMAX: If GI-DS-lite is applied to mobile WiMAX, the home
      agent will implement the Gateway function.

   o  PPP-based broadband access architectures: If GI-DS-lite is applied
      to PPP-based access architectures the Broadband Remote Access
      Server (BRAS) or Broadband Network Gateway (BNG) will implement
      the GI-DS-lite Gateway function.

   o  In broadband access architectures using per-subscriber VLANs the
      BNG will implement the GI-DS-lite Gateway function.


8.  Acknowledgements

   The authors would like to acknowledge the discussions on this topic
   with Mark Grayson, Jay Iyer, Kent Leung, Vojislav Vucetic, Flemming
   Andreasen, Dan Wing, Jouni Korhonen, Teemu Savolainen, Parviz Yegani,



Brockners, et al.       Expires September 9, 2010              [Page 10]


Internet-Draft          Gateway-Initiated DS-Lite             March 2010


   Farooq Bari, Mohamed Boucadair, Vinod Pandey, Jari Arkko and Eric
   Voit.


9.  IANA Considerations

   This document includes no request to IANA.

   All drafts are required to have an IANA considerations section (see
   the update of RFC 2434 [RFC5226] for a guide).  If the draft does not
   require IANA to do anything, the section contains an explicit
   statement that this is the case (as above).  If there are no
   requirements for IANA, the section will be removed during conversion
   into an RFC by the RFC Editor.


10.  Security Considerations

   All the security considerations from GTP [TS29060], Mobile IPv6
   [RFC3775], Proxy Mobile IPv6 [RFC5213], and Dual-Stack lite
   [I-D.ietf-softwire-dual-stack-lite] apply to this specification as
   well.


11.  References

11.1.  Normative References

   [I-D.ietf-softwire-dual-stack-lite]
              Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee,
              Y., and R. Bush, "Dual-stack lite broadband deployments
              post IPv4 exhaustion",
              draft-ietf-softwire-dual-stack-lite-03 (work in progress),
              February 2010.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC2890]  Dommety, G., "Key and Sequence Number Extensions to GRE",
              RFC 2890, September 2000.



Brockners, et al.       Expires September 9, 2010              [Page 11]


Internet-Draft          Gateway-Initiated DS-Lite             March 2010


   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5555]  Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
              Routers", RFC 5555, June 2009.

11.2.  Informative References

   [I-D.draft-ietf-dime-nat-control]
              Brockners, F., Bhandari, S., Singh, V., and V. Fajardo,
              "Diameter NAT Control Application", August 2009.

   [I-D.ietf-bfd-base]
              Katz, D. and D. Ward, "Bidirectional Forwarding
              Detection", draft-ietf-bfd-base-11 (work in progress),
              January 2010.

   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              February 2006.

   [TR101]    Broadband Forum, "TR-101: Migration to Ethernet-Based DSL
              Aggregation", April 2006.

   [TR59]     Broadband Forum, "TR-059: DSL Evolution - Architecture
              Requirements for the Support of QoS-Enabled IP Services",
              September 2003.

   [TS23060]  "3rd Generation Partnership Project; Technical
              Specification Group Services and System Aspects; General
              Packet Radio Service (GPRS); Service description; Stage
              2.", 2009.

   [TS23401]  "3rd Generation Partnership Project; Technical
              Specification Group Services and System Aspects; General
              Packet Radio Service (GPRS) enhancements for Evolved
              Universal Terrestrial Radio Access Network (E-UTRAN)
              access.", 2009.

   [TS29060]  "3rd Generation Partnership Project; Technical
              Specification Group Core Network and Terminals; General



Brockners, et al.       Expires September 9, 2010              [Page 12]


Internet-Draft          Gateway-Initiated DS-Lite             March 2010


              Packet Radio Service (GPRS); GPRS Tunnelling Protocol
              (GTP), V9.1.0", 2009.


Authors' Addresses

   Frank Brockners
   Cisco
   Hansaallee 249, 3rd Floor
   DUESSELDORF, NORDRHEIN-WESTFALEN  40549
   Germany

   Email: fbrockne@cisco.com


   Sri Gundavelli
   Cisco
   170 West Tasman Drive
   SAN JOSE, CA  95134
   USA

   Email: sgundave@cisco.com


   Sebastian Speicher
   Deutsche Telekom AG
   Landgrabenweg 151
   BONN, NORDRHEIN-WESTFALEN  53277
   Germany

   Email: sebastian.speicher@telekom.de


   David Ward
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, California  94089-1206
   USA

   Email: dward@juniper.net











Brockners, et al.       Expires September 9, 2010              [Page 13]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/