Network Working Group Q. Wu T.Taylor Internet Draft Huawei H.Deng China Mobile Intended status: Standard Track March 3, 2009 Expires: September 2009 MIP Extension for Ethernet Service Support draft-wu-mip4-ether-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. 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 August 3, 2009. Wu Expires September 3, 2009 [Page 1] Internet-Draft MIP Extension for Ethernet Service Support March 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 (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. Abstract The IP Mobility Protocol [RFC3344] enables node to maintain IP connectivity when node changes the location. However it is ideal to support forwarding ethernet frame between mobile node and ethernet service provider. 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. Table of Contents 1. Introduction.................................................3 2. Conventions used in this document............................3 3. Scenarios for MIP based Ethernet Services....................4 3.1. Coexistence of services for the same access network.....4 3.2. Switched Ethernet Access Network........................5 4. Processing Consideration.....................................6 4.1. GRE Encapsulation Support...............................6 4.2. Ethernet Service Support................................6 5. Mobile Node Consideration....................................7 6. Foreign Agent Consideration..................................7 6.1. Extension to registration tables for the foreign Agent..7 6.2. Foreign Agent Operation.................................7 7. Home Agent Consideration.....................................8 7.1. Extension to registration tables for the home Agent.....8 7.2. Home Agent Operation....................................8 8. Message Format...............................................9 8.1. Ethernet Extension Mobility Option......................9 8.2. GRE Extension option....................................9 9. Security Considerations......................................9 10. IANA Considerations........................................10 11. References.................................................10 11.1. Normative References..................................10 Wu Expires September 3, 2009 [Page 2] Internet-Draft MIP Extension for Ethernet Service Support March 2009 11.2. Informative References................................10 1. Introduction The IP Mobility Protocol [RFC3344] enables node to maintain IP connectivity when node changes the location. However in some mobile IPv4 scenarios, enable node to maintain IP connectivity is not enough to support forwarding ethernet frame between mobile node and ethernet service provider (e.g. ASP), i.e. ethernet 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. Conventions used in this document 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 RFC-2119. Wu Expires September 3, 2009 [Page 3] Internet-Draft MIP Extension for Ethernet Service Support March 2009 The document uses the terminology specified in [RFC 3344]. In addition, this document defines the following: Ethernet Extension 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, two use cases are listed that are identified for Ethernet Service Support: Coexistence of IP services and Ethernet services for the same Access network, Switched Ethernet access network. 3.1. Coexistence of services for the same access network The figure 1 shows coexistence of IP services and Ethernet service for the same access network. In this scenario, the ASP in the fixed network provides ethernet service contains the bridging function for forwarding Ethernet frames between MN and the Ethernet Service provider while the MSP in the mobile network provides IP service (e.g., Internet) delivered between the foreign agent and the home agent through the same access network. When Mobile IP is applied for dynamic tunnel management between the foreign agent 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. When the MN is not the end system but contains a bridge forwarding to end systems behind the MN, the downlink Ethernet frames contain destination MAC addresses other than the MN MAC address. Wu Expires September 3, 2009 [Page 4] Internet-Draft MIP Extension for Ethernet Service Support March 2009 +-----------+ --------- | ASP | /// \\\ | Providing | +-------+ Access Network \ | Ethernet | | | | +------+ | +------ /| Service | | MN | | | FA +----+--+ HA X +-----------+ +-------+ | +------+ | +------+\ | | \ ----- \ / \// \\ \\\ /// | Internet| --------- \\ // ----- Figure 1 Coexistence of IP services and Ethernet services for the same access network 3.2. Switched Ethernet Access Network Figure 2 shows one use case for interoperable implementations of various access networks in which Ethernet aggregation is used instead of IP- based tunnels for the data paths between the foreign agent in different access network and the home agent in the core network. The ASP in the fixed network provides ethernet service contains the bridging function for forwarding Ethernet frames to the home agent. In this scenario, each access network is connected on the network side to the Core network via an Ethernet aggregation network for concentration and forwarding of the data path. The IP-based control plane between the access network and the Core network is also carried over the Ethernet aggregation network. The particular Ethernet protocol for the data path mentioned above is not specified and depends on the kind of services provided by the Core network to the MN or the host behind the MN. Here the host is the end system behind the MN. Wu Expires September 3, 2009 [Page 5] Internet-Draft MIP Extension for Ethernet Service Support March 2009 Access Network 1 +-------+ /---------\ | | //// +------+ \\\\ | MN | | | FA +-----| +-----------+ +-------+ | +------+ \ +--------+ | ASP | | \\\\ //// \ | +---+ Providing | | \---------/ \| HA | | Ethernet | | /---------\ /+--------+ | Service | | Access Network 2 \\\\ / +-----------+ +--\/---+ | +------+ / | | | | FA +-----| | MN | \\\\ +------+ //// +-------+ \---------/ Figure 2 Switched Ethernet access network 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. [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 difference 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 to marking downlink and uplink traffic for a specific flow. 4.2. Ethernet Service 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. Ethernet frame can be carried over IP tunnel or Ethernet aggregation network between the foreign agent and the home agent. During binding registration procedure, the FA must on behalf of MN send registration request message to the home agent with MN's MAC address included in the ethernet extension mobility 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, GRE key and the FA CoA in its own registration tables. Also it can 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. Wu Expires September 3, 2009 [Page 6] Internet-Draft MIP Extension for Ethernet Service Support March 2009 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. 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 two new 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 The hosts MAC address behind MN The hosts MAC address behind MN used to bind with FA CoA when learning it from uplink frame received from host 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 also allocate the GRE key and will include it in the GRE extension. Upon receiving 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 devices connected to a bridge behind MN. 7. Home Agent Consideration 7.1. Extension to registration tables for the home Agent Every home agent maintains a registration tables 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 two new 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 hosts MAC address behind MN The hosts MAC address behind MN used to bind with FA CoA when learning it from uplink frame received from host 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. Wu Expires September 3, 2009 [Page 8] Internet-Draft MIP Extension for Ethernet Service Support March 2009 After successful registration, the home agent will start capturing the Ethernet frames on the home link destined to the registered MN's 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 case, 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 response messages exchanged between the foreign agent and the home agent. This option can be used for the Home agent and the foreign 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. GRE Extension option The details are defined in section 5 of [draft-yegani-gre-key-extension- 03]. 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. Wu Expires September 3, 2009 [Page 9] Internet-Draft MIP Extension for Ethernet Service Support March 2009 10. IANA Considerations 11. References 11.1. Normative References [RFC3344] Perkin, C., " IP Mobility Support for IPv4 ", RFC 3344, August 2002. [RFC2003] Perkin, C.,Solomo, J., " IP Encapsulation within IP ", RFC 2003, October, 1996. [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000. [RFC2890] Dommety, G., " Key and Sequence Number Extensions to GRE ", RFC 2890, September, 2000. 11.2. Informative References [draft-yegani-gre-key-extension-03] Yegani, P., Dommety, G., " GRE Key Extension for Mobile IPv4 ", draft-yegani-gre-key- extension-03,June,2007. Wu Expires September 3, 2009 [Page 10] Internet-Draft MIP Extension for Ethernet Service Support March 2009 Authors' Addresses Qin Wu Huawei Technologies Co.,Ltd Site B,Floor 12F,Huihong Mansion,No.91,Baixia Rd. Nanjing 210001 China Phone: +86-25-84565892 Email: Sunseawq@huawei.com Tom Taylor Huawei Technologies Co.,Ltd 1852,Lorraine Ave Ottawa,Ontario K1H 6Z8 Canada Email: tom.taylor@rogers.com Hui Deng China Mobile 53A, Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: denghui02@gmail.com Wu Expires September 3, 2009 [Page 11]