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

Versions: 00 01 02

Network Working Group                                         Q. Wu, Ed.
Internet-Draft                               Huawei Technologies Co.,Ltd
Intended status: Standards Track                              S. Rahman
Expires: November 13, 2009                                      Ericsson
                                                                 H. Deng
                                                            China Mobile
                                                            May 12, 2009


          MIP Extension for Ethernet Service transport Support
                         draft-wu-mip4-ether-02

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 November 13, 2009.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.






Wu, et al.              Expires November 13, 2009               [Page 1]


Internet-Draft              Ethernet In MIPv4                   May 2009


Abstract

   The IP Mobility Protocol [RFC3344] enables a mobile node maintain IP
   connectivity when it changes its location.  However, it is not enough
   to enable the node to maintain L2 connectivity between mobile node
   and Ethernet service provider in order to support Ethernet service
   transport.  This document describes "Ethernet Service Transport"
   mobility option for mobile IPv4 that is intended to assist home agent
   tunnel Ethernet packets from the home link to the FA on the foreign
   link during the datagram delivery process.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Scenarios for MIP based Ethernet Services  . . . . . . . . . .  4
     3.1.  Hybrid services transport  . . . . . . . . . . . . . . . .  4
     3.2.  Native Ethernet Service Transport  . . . . . . . . . . . .  5
     3.3.  VLAN Tag Support . . . . . . . . . . . . . . . . . . . . .  5
     3.4.  Multi-Host Support . . . . . . . . . . . . . . . . . . . .  6
   4.  Processing Consideration . . . . . . . . . . . . . . . . . . .  7
     4.1.  GRE Encapsulation Support  . . . . . . . . . . . . . . . .  7
     4.2.  Ethernet Service Transport Support . . . . . . . . . . . .  7
   5.  Mobile Node Consideration  . . . . . . . . . . . . . . . . . .  7
   6.  Foreign Agent Consideration  . . . . . . . . . . . . . . . . .  8
     6.1.  Extension to registration tables for the Foreign Agent . .  8
     6.2.  Foreign Agent Operation  . . . . . . . . . . . . . . . . .  8
   7.  Home Agent Consideration . . . . . . . . . . . . . . . . . . .  9
     7.1.  Extension to registration tables for the Home Agent  . . .  9
     7.2.  Home Agent Operation . . . . . . . . . . . . . . . . . . .  9
   8.  Message Format . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.1.  Ethernet Extension Mobility Option . . . . . . . . . . . . 10
     8.2.  Vendor specific Extension Option . . . . . . . . . . . . . 10
     8.3.  GRE Extension option . . . . . . . . . . . . . . . . . . . 10
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   10. IANA considerations  . . . . . . . . . . . . . . . . . . . . . 11
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     11.2. Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12










Wu, et al.              Expires November 13, 2009               [Page 2]


Internet-Draft              Ethernet In MIPv4                   May 2009


1.  Introduction

   The IP Mobility Protocol[RFC3344]enables a mobile node maintain IP
   connectivity when it changes its location.  However, in some mobile
   IPv4 scenarios, enabling the node maintain its L2 connectivity is
   required to support forwarding Ethernet frames between mobile node
   and Ethernet service provider (e.g.  ASP), i.e.  "Ethernet Service
   Transport" support.

   The capability to support Ethernet service can facilitate mobility
   service providers to provider IP services as well as Ethernet
   services concurrently over the same infrastructure within the same
   mobility service subscription.  For example:

   o  Provide end to end Ethernet connectivity from the mobile node
      across access network to the ASP providing Ethernet services (e.g.
      connectivity to DSL network with PPPoE).

   o  Ethernet service support within the access network, e.g., node
      movement from one Ethernet segment to another within the same
      access network.  It allows transport Ethernet frame between mobile
      node and the mobility anchor(e.g.  FA).

   o  Provide Ethernet aggregation for the public access service which
      imposes Ethernet frame to pass through ISP-head end to enable
      accouting and enforce security policies.

   This document describes Ethernet extension mobility option for mobile
   IPv4 that is intended to assist home agent to tunnel Ethernet frame
   on the home link to the FA in the foreign link during datagram
   delivery process after the binding registration procedure.  Ethernet
   service support for mobile IPv4 may affect the home agent routing
   decision, home address assignment polices and tunnel setup mechanism.
   Support of Ethernet does not require a new network architecture or
   any new functional entities in the network.  The support of Ethernet
   Services is smoothly integrated into the Mobile network architecture
   and Ethernet services can be operated parallel to the IP Services in
   the same network.


2.  Terminology

   The keywords "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 document uses the terminology specified in [RFC3344], In
   addition, this document defines the following:



Wu, et al.              Expires November 13, 2009               [Page 3]


Internet-Draft              Ethernet In MIPv4                   May 2009


   Ethernet service transport

      Ethernet support for Mobile IPv4 that assists home agent to tunnel
      Ethernet frame on the home link to the FA in the foreign link
      during datagram delivery process after the binding registration
      procedure.

   GRE Extension

      GRE Encapsulation support for Mobile IPv4 that is used to
      differentiate between difference Ethernet services or flows.


3.  Scenarios for MIP based Ethernet Services

   In this section, four use cases are listed that are identified for
   Ethernet service transport support.

3.1.  Hybrid services transport

   The figure 1 shows coexistence of IP services and Ethernet service
   for the same mobile node in the same access network.  In this
   scenario, the ASP providing Ethernet service contains the bridging
   function for forwarding Ethernet frames between MN and the Ethernet
   Service provider while the MSP (Mobile service Provider) provides IP
   service (e.g., Internet) delivered between the foreign agent or
   mobile node and the home agent through the same access network to the
   same mobile node.  When Mobile IP is applied for dynamic tunnel
   management between the foreign agent or the mobile node and the home
   Agent, the GRE based tunnel enables the transport of Ethernet frames
   in the payload.  The Ethernet frames are forwarded based on the MN
   MAC address.

             |                     |        |
             |                     |        | +----------------+
             |   Access Network    |        +-+ASP providing   |
          +--+--+  //----\\  +-----+-+      | |Ethernet Service|
    MN    | FA  | |        | | HA    |      | +----------------+
          +--+--+  \\----//  |  +--------+  |
             |               +--|Ethernet|  | +----------------+
             |                  |bridge  +--+ |MSP providing   |
             |                  +--+-----+  +-+IP Service      |
             |                     |        | +----------------+
             |                     |        |
             |                     |        |
             |                     |        |
            Figure 1 Coexistence of IP services and Ethernet
                services for the same access network



Wu, et al.              Expires November 13, 2009               [Page 4]


Internet-Draft              Ethernet In MIPv4                   May 2009


3.2.  Native Ethernet Service Transport

   Figure 2 shows native Ethernet sevice transport over various access
   networks in which it allows node movement from one Ethernet segment
   to another within the same access network or across various access
   networks.  The Ethernet frames are distinguished by the bridging
   function at the HA based on VSE(Vendor Specific Extension) or host
   port and transport them over IP based tunnels between the foreign
   agent or Mobile node and the home agent.

                   |Access Network1
                 --|---
              ///  |   \\\            |         |
    +--+    ||   +-|--+   |           |         |
    |MN|    |    | FA |    |\         |         |
    +--+    ||   +-|--+   |  \        |         | +----------------+
              \\\  |   ///    \  +----|---+     ---ASP Providing   |
                 --|---        \ | HA     |     | |Ethernet Service|
                /--|---\       / |   +--------+ | +----------------+
    +--+     /// +-|--+ \\\   /  +---|Ethernet| |
    |MN|    |    | FA |    | /       |bridge  ---
    +--+    |    +-|--+    |/        +|-------+ |
             \\\   |    ///           |         |
                \--|---/              |         |
                   |Access Network2   |         |
                   |                  |         |
            Figure 2 Native Ethernet Service Transport


3.3.  VLAN Tag Support

   Figure 3 shows VLAN Tag Support.  VLAN-IDs are used in many different
   ways for segregating traffic of Ethernet services in the access
   network.  The L2FW function in the FA SHALL support the flexible use
   of the VLAN-IDs by providing the following capabilities for each of
   the service flows:

   In downstream direction towards the MN:

      The L2FW SHALL be able to remove VLAN tags if present.

   In upstream direction from the MN:

      The L2FW SHALL be able to insert VLAN tags and assign priority
      bits in the VLAN tags.

   Also the Ethernet bridge in the HA SHALL support VLAN tags process in
   bidirection towards or from the FA.



Wu, et al.              Expires November 13, 2009               [Page 5]


Internet-Draft              Ethernet In MIPv4                   May 2009


               |
               |                                   |
               |                ------             |
               |             ///      \\\\         |
           +---+-------+   //             \  +-----+-----+
  +----+   | FA        |  |                | |HA         |
  | MN |   | +-+-------+-+| Access network | |   +-------+--+
  +----+   | |           ||                | |   |          |
           +-+    L2FW   | \\            //  +---+ Ethernet |
             |           |   \\\      ///        | bridge   |
             +-+---------+      ------           +-+-----+--+
               |                                   |     |
               |                                   |  +--+-------------+
               |                                   |  |ASP providing   |
               |                                   |  |Ethernet Service|
               |                                   |  +----------------+
                  Figure 3 VLAN Tags Support



3.4.  Multi-Host Support

   Figure 4 shows multi-host support.  In the multi-host scenarios,
   there are multiple devices connected to a bridge behind MR or RG.  In
   this sense, the MR/RG is not the end system but contains a bridge
   forwarding to end systems behind the MR/RG, the downlink Ethernet
   frames contain destination MAC addresses other than the MR or RG MAC
   address, the Ethernet bridge attached to the home agent can learn the
   MAC addresses of the hosts behind the MR and establish binding
   between these MAC addresses and FA CoA when those hosts become active
   and start sending uplink frames.


                 |       |                   |
  +-----+        |       |                   |        +----------------+
  |Host1|\       |       |                   |        |ASP providing   |
  +-----+ \      |       | Access network    |        |Ethernet Service|
  +-----+   \ +--+--+  +-+--+  //---\\   +---+-----+  +-------+--------+
  |Host2+-----|MR/RG|  | FA | |       |  | HA      |          |
  +-----+   / +--+--+  +-+--+  \\---//   |   +-----+--+       |
  +-----+  /     |       |               +---+Ethernet+-------|
  |Host3| /      |       |                   |bridge  |
  +-----+        |       |                   +--------+
                 |       |                   |
                 |       |                   |
                    Figure 4 Multi-Host Support





Wu, et al.              Expires November 13, 2009               [Page 6]


Internet-Draft              Ethernet In MIPv4                   May 2009


4.  Processing Consideration

4.1.  GRE Encapsulation Support

   [RFC2003]allows IP in an IP encapsulation which can be used to tunnel
   traffic between the FA and the HA.  However, this encapsulation
   method is not enough to identify the destination of packets of a
   specific flow within an IP-in-IP tunnel.

   [RFC2890]describes one generic routing encapsulation method which can
   be used to distinguish different flows in terms of GRE key.  Thus,
   GRE encapsulation is one best way to differentiate between different
   Ethernet services or flows, i.e., during binding registration
   procedure, the message exchange between the FA and the HA will be
   used to negotiate downlink and uplink GRE keys which is used for
   marking downlink and uplink traffic for a specific flow.

4.2.  Ethernet Service Transport Support

   In order to support Ethernet service delivery in mobile IPv4
   scenario, the communication between the MN and the home agent needs
   to be modified to support Ethernet frame transport.  Ethernet frame
   can be transported over IP tunnel between the foreign agent and the
   home agent.  During registration procedure, the MN or FA on behalf of
   MN sends Registration Request message to the home agent with MN's MAC
   address included in the Ethernet transport mobility option and MN's
   port included in the VSE option, meanwhile the FA will bind MN's MAC
   address, GRE key to the FA CoA in its own registration tables.  Upon
   receiving Registration Request, the home agent will establish binding
   among MN's MAC address, port, GRE key and the FA CoA in its own
   registration tables.  It can also learn the MAC addresses of the
   hosts behind the MN and establish binding between these MAC addresses
   and FA CoA in its own registration tables when those hosts become
   active and send some uplink frames.  After successful registration,
   the home agent will start capturing the Ethernet frames on the home
   link destined to the registered MN's MAC address based on the host
   port or VSE containing MN port and forward those frames to the FA via
   GRE tunnel.


5.  Mobile Node Consideration

   If the mobile node is capable of supporting Ethernet service, it
   should be authenticated for network access and authorized for the
   specific Ethernet service.  After that, a set of pre-provisioned
   service flows for Ethernet service and IP service can be created,
   admitted and activated between the MN and the foreign agent.




Wu, et al.              Expires November 13, 2009               [Page 7]


Internet-Draft              Ethernet In MIPv4                   May 2009


6.  Foreign Agent Consideration

6.1.  Extension to registration tables for the Foreign Agent

   Every foreign agent maintains a registration table for each currently
   attached mobile node, as explained in section 3.8.1 of the mobile
   IPv4 specification [RFC3344].  To support this specification, the
   conceptual registration table data structure must be extended with
   the following additional fields:

   The MN's MAC address

      The MN's MAC address used to bind with FA CoA during binding
      registration procedure and tunnel Ethernet frame to MN's MAC
      address. such as Loss of HA-HELLO, Monitored Server Failure by the
      Active HA, Routing Peer/ Link Failure.  Each LMA should exchange
      HA-HELLO (can be renamed as LMA-HELLO) for failure detection.

   The host MAC addresses behind MN

      The host MAC addresses behind MN used to bind with FA CoA when
      learning those from uplink frames received from hosts behind MN.

   The MN's GRE key

      The MN's GRE key assigned by the FA and the HA and used to
      distinguish the destination of packets of a specific flow which
      include uplink GRE key and downlink GRE key.

6.2.  Foreign Agent Operation

   In the foreign agent care-of address mode[RFC3344], during binding
   registration procedure, the FA starts the establishment of a dynamic
   tunnel by sending or forwarding the Registration Request message to
   the indicated HA.  The Registration Request will contain the MN's
   NAI[RFC2794], IPv4 home address field will be set to all zeros and
   the MN's MAC address will be included in the new MIPv4 extension
   called Ethernet extension.  When the FA forwards the Registration
   Request to the home agent with MN's MAC address carried in the
   Ethernet extension mobility option, it will bind MN's MAC address,
   GRE key to the FA CoA in its own registration tables.  Also it
   requests GRE encapsulation to differentiate between difference
   Ethernet services or flows.  In addition to setting Wu Expires
   September 3, 2009 [Page 7] Internet-Draft MIP Extension for Ethernet
   Service Support March 2009 the G flag in Registration Request
   message, the FA will allocate the GRE key and will include it in the
   GRE extension.




Wu, et al.              Expires November 13, 2009               [Page 8]


Internet-Draft              Ethernet In MIPv4                   May 2009


   Upon receiving a frame tunneled by home agent on the home link after
   binding registration, the FA will identify the MN to which the frame
   must be delivered.  The FA will not use the data from the inner
   packet header (i.e.  MAC addresses) to identify the corresponding MN.
   The received GRE key will be used to identify the MN to which the
   encapsulated payload must be delivered.  This is advantageous in case
   that there are multiple Ethernet devices connected to a bridge behind
   the MN.


7.  Home Agent Consideration

7.1.  Extension to registration tables for the Home Agent

   Every home agent maintains a registration table for each currently
   attached mobile node, as explained in section 3.8.1 of the mobile
   IPv4 specification [RFC3344].  To support this specification, the
   conceptual registration table data structure must be extended with
   the following additional fields:

   The MN's MAC address

      The MN's MAC address used to bind with FA CoA during binding
      registration procedure and tunnel Ethernet frame to MN MAC
      address.

   The host MAC addresses behind MN

      The host MAC addresses behind MN used to bind with FA CoA when
      learning those from uplink frames received from hosts behind MN.

   The MN's GRE key

      The MN's GRE key assigned by the FA and the HA and used to
      distinguish the destination of packets of a specific flow which
      include uplink GRE key and downlink GRE key.

7.2.  Home Agent Operation

   When the home agent receives the Registration Request message from
   the the foreign agent, it will bind the MN's MAC address contained in
   the Ethernet extension to the FA CoA(i.e., IP address of FA).  It
   will also save the received GRE key as part of its mobility binding
   context.  Home agent will also allocate its own GRE key and send it
   to FA in MIP Registration Reply.

   After successful registration, the home agent will start capturing
   the Ethernet frames on the home link destined to the registered MN's



Wu, et al.              Expires November 13, 2009               [Page 9]


Internet-Draft              Ethernet In MIPv4                   May 2009


   MAC address and forwarding those frames to the FA via GRE tunnel.
   The home agent must include the FA's GRE key in the GRE packet
   header.  In some cases, the bridge attached to the home agent can
   learn the MAC addresses of the hosts behind the MN and establish
   binding between these MAC addresses and FA CoA when those hosts
   become active and send some uplink frames.  Having learnt the
   address(es) behind the MN, the bridge behind the home agent would
   start tunneling the frames on the home link destined to those MAC
   addresses over the established GRE tunnel, tagging the tunneled
   packets with the GRE key associated with the MN.  Upon receiving
   frame in the uplink direction from the foreign agent, the home agent
   will use the received GRE key (instead of the source address from the
   inner header) to find the corresponding mobility context.


8.  Message Format

8.1.  Ethernet Extension Mobility Option

   A new mobility option, the Ethernet Extension mobility option, is
   defined for use in the Registration Request and Registration Reply
   messages exchanged between the foreign agent and the home agent.
   This option can be used for the home agent and the foreign agent to
   identify the MN to which the frame must be delivered.

        0                   1                   2                   3
        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Type = TBD   |   Length      |          Reserved             |
      -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    MN MAC Address
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 3 Ethernet Extension Mobility Option

8.2.  Vendor specific Extension Option

   A VSE option is defined in the Registration Request and Registration
   Reply message.  This option can be used to distinguish between IP
   service and Ethernet service or between different Ethernet services.
   The VSE can contain MN port and/or additional service parameters,
   which is outside the scope of this document.

8.3.  GRE Extension option

   The details are defined in section 5 of
   [draft-yegani-gre-key-extension].




Wu, et al.              Expires November 13, 2009              [Page 10]


Internet-Draft              Ethernet In MIPv4                   May 2009


9.  Security Considerations

   The Ethernet Extension Mobility Option and the functionalities in
   this document are protected by the Authentication Extensions
   described in[RFC3344]].  The FA needs to have a security association
   with the HA to register the MN's IP address.  The security
   association can be provisioned by the administrator, or dynamically
   derived.


10.  IANA considerations

   TBA


11.  References

11.1.  Normative References

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

   [RFC3344]  Perkin, C., "IP Mobility Support for IPv4", August 2002.

   [RFC2003]  Perkin, C. and J. Perkin, "IP Encapsulation within IP",
              October 1996.

   [RFC2794]  Calhoun, P. and C. Perkin, "Mobile IP Network Access
              Identifier Extension for IPv4", March 2000.

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

   [RFC4448]  Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
              "Encapsulation Methods for Transport of Ethernet over MPLS
              Networks", RFC 4448, April 2006.

   [RFC4719]  Aggarwal, R., Townsley, M., and M. Dos Santos, "Transport
              of Ethernet Frames over Layer 2 Tunneling Protocol Version
              3 (L2TPv3)", RFC 4719, November 2006.

11.2.  Informative References

   [draft-yegani-gre-key-extension]
              Yegani, P. and G. Dommety, "GRE Key Extension for Mobile
              IPv4", draft-yegani-gre-key-extension-03 (work in
              progress), June 2007.




Wu, et al.              Expires November 13, 2009              [Page 11]


Internet-Draft              Ethernet In MIPv4                   May 2009


Authors' Addresses

   Qin Wu (editor)
   Huawei Technologies Co.,Ltd
   Site B,Floor 12F,Huihong Mansion, No.91 Baixia Rd.
   Nanjing, Jiangsu  21001
   China

   Phone: +86-25-84565892
   Email: Sunseawq@huawei.com


   Shah Rahman
   Ericsson
   100 Headquarters Drive
   San Jose, CA  95134
   USA

   Email: shah.rahman@ericsson.com


   Hui Deng
   China Mobile
   53A, Xibianmennei Ave. Xuanwu District,
   Beijing  100053
   China

   Email: denghui02@gmail.com























Wu, et al.              Expires November 13, 2009              [Page 12]


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