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]