One document matched: draft-wu-mip4-ether-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 14:46:39 |