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]