One document matched: draft-jeyatharan-mext-flow-tftemp-reference-00.txt
MEXT Working Group M. Jeyatharan
Internet-Draft C. Ng
Intended status: Standards Track Panasonic
Expires: September 3, 2010 March 2, 2010
3GPP TFT Reference for Flow Binding
draft-jeyatharan-mext-flow-tftemp-reference-00
Abstract
This memo describes a reference to third generation partner ship
project (3GPP) defined traffic flow template (TFT) as a traffic
selector in the flow based routing mechanism described in the flow
binding draft [1]. This memo, further specifies a new traffic
selector sub-option format to be used with the flow binding mobility
option defined in draft [1], in order to transport the TFT reference
from the mobile node to its home agent in a 3GPP SAE (service
architecture evolution) scenario.
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 September 3, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Jeyatharan & Ng Expires September 3, 2010 [Page 1]
Internet-Draft TFT Reference March 2010
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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4
4.1. Setting up Flow Filters . . . . . . . . . . . . . . . . . 5
4.2. Refreshing Flow Filters . . . . . . . . . . . . . . . . . 5
4.3. Modification of TFTs . . . . . . . . . . . . . . . . . . . 6
4.4. Removal of TFTs . . . . . . . . . . . . . . . . . . . . . 6
5. Modification to Existing Protocol . . . . . . . . . . . . . . 6
5.1. TFT Reference Traffic Selector Sub-option Format . . . . . 6
6. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 7
7. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative Reference . . . . . . . . . . . . . . . . . . . 9
10.2. Informative Reference . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Jeyatharan & Ng Expires September 3, 2010 [Page 2]
Internet-Draft TFT Reference March 2010
1. Introduction
A mobile node which has the ability to manage its mobility as
described in RFC-3775 [2], RFC-3963 [8] or RFC-5555 [9] may connect
to the operator's core network using multiple interfaces as described
in RFC-5648 [3]. After attaching to the core network using multiple
interfaces, the mobile node can then set flow based routing rules at
its home agent using the method outlined in draft MEXT-FlowBinding
[1]. MEXT-FlowBinding [1] specifies a method for the mobile node to
send the flow identifier mobility option and the traffic selector
sub-option in the binding update mobility header. The flow
identifier mobility option is used to specify the routing rules and
the traffic selector sub-option is used to characterize the flows to
which the routing rules apply. The flow binding mechanism can be
used with any traffic selector sub-option format. Currently defined
traffic selector is the binary format specified in [4].
In 3GPP evolved packet system (EPS), QoS is provisioned by creating
multiple EPS bearer [5]. Each EPS bearer is identified by a EPS
bearer identifier (ID) and may be associated with different QoS
parameters such as the QoS class indicator (QCI), maximum bit-rate,
guaranteed bit rate, etc. All traffic sent along a given EPS bearer
will enjoy the same level of QoS.
In order to forward flows according to their subscribed QoS classes,
the EPS bearers are each associated with Traffic Flow Template (TFT)
which contain a list of Packet Filters [6]. Each packet filter
describes a flow by parameters such as remote party (correspondent
node) IP address, source and destination port numbers, flow label,
transport protocol etc. With TFTs, both the network and the mobile
node can make the selection of the appropriate EPS bearer to forward
a given packet so that correct QoS treatment is used when forwarding
the packet.
2. Motivation
There is a 3GPP release 10 standardization effort as described in
[10] which allows simultaneous 3GPP and non-3GPP accesses and flow
mobility for mobile nodes that have client based mobility management
protocols. The mobile node may set flow based routing rules using
the method outlined in draft MEXT-FlowBinding [1] to select the
interface for the delivery of a particular flow. When the flow is
directed to the 3GPP interface, the TFT mechanism is then used to
select which EPS bearer to deliver the flow so that appropriate QoS
treatment can be applied.
A likely scenario is for the mobile node to set the non-3GPP
Jeyatharan & Ng Expires September 3, 2010 [Page 3]
Internet-Draft TFT Reference March 2010
interface as the default interface, and use the 3GPP interface for
flows that require QoS treatment. In such cases, it is necessary for
the mobile node to set the flow based routing rules correctly so that
the flows are routed to the 3GPP interface. The routing rules set in
this situation is likely to be identical to the TFTs installed for
the EPS bearers. In this memo, the term routing filter refers to
flow filter that is described in MEXT-FlowBinding [1] and will be
used interchangeably. Additionally, when the TFT is changed (eg. to
accommodate additional flows for guaranteed QoS treatment, or an
existing flow is no longer qualified to enjoy special QoS treatment),
it is expected for the mobile node to modify corresponding routing
rules accordingly.
Based on the above, it will be beneficial for there to be a mechanism
for the mobile node to reference the TFT installed in a particular
EPS bearer as the filter description in the binding update message.
This reduces the size of binding update messages, reduces the amount
of binding update messages needed, and also eliminates the
possibility of a flow not getting appropriate QoS treatment due to a
mismatch between the routing rules and the installed TFT. With this
in mind, the objective of this memo is to introduce mechanism for
referencing a TFT installed on an EPS bearer when setting filter
rules using the flow binding mechanism as described in MEXT-Binding
[1].
Section 4 will first present an overview of installing routing
filters using TFT as a reference for flows. Next, Section 5 lists
the required protocol changes to carry the reference to TFT as a new
traffic selector sub-option called the TFT reference traffic selector
sub-option. The mobile node and home agent operations with respect
to this new TFT reference traffic selector are then described in
Section 6 and Section 7 respectively. Finally, Section 8 discusses
the IANA support needed and Section 9 discusses the security
considerations.
3. Requirements Notation
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 [7].
4. Overview of Operation
Jeyatharan & Ng Expires September 3, 2010 [Page 4]
Internet-Draft TFT Reference March 2010
4.1. Setting up Flow Filters
When a mobile node simultaneously attaches to both a 3GPP access and
a non-3GPP access, and has TFT installed in one or more EPS Bearer on
the 3GPP access, the mobile node will send a binding update (i) to
perform a simultaneously at home and away binding as described in
RFC-5648 [3] and (ii) to install routing filters corresponding to the
TFTs to ensure that flows which are eligible for QoS treatment be
routed to the 3GPP access. For example, if there is a TFT containing
packet filters which route a video flow to an EPS bearer of EPS
bearer ID 1, the mobile node sends a binding update (BU) to ensure
that the video flow is routed to the 3GPP access by the home agent.
This is done by including a TFT reference traffic selector sub-option
to indicate to the home agent that a routing rule should be generated
from the TFT associated with the EPS bearer that is referenced in the
TFT reference traffic selector sub-option. Figure 1 illustrates the
contents of the BU message. The BU mobility header will contain two
Binding Identifier (BID) mobility option to bind the 3GPP access as a
home binding and the non-3GPP access as a care-of binding. Since
non-3GPP access is the default interface, it is set with a low BID
priority value (implying high priority). A Flow Identifier (FID)
mobility option is included that carries the TFT reference traffic
selector sub-option (described in Section 5.1), and will carry a
reference to EPS bearer ID 1.
IPv6 Header
BU Mobility Header
Mobility Options
BID option [for care-of binding of non-3GPP access]
BID option [for home binding of 3GPP access]
FID option
TFT reference traffic selector sub-option [EPS bearer ID 1]
Figure 1: BU packet with TFT reference when non-3GPP is default
access
Once the home agent receives and successfully process such binding
update message with TFT reference traffic selector sub-option, it
will install the corresponding simultaneous at home and away
registration. The home agent will also locate the packet filters in
the TFTs referred to by the TFT reference traffic selector sub-option
and install relevant routing rules based on a one-to-one conversion
from each located Packet Filter.
4.2. Refreshing Flow Filters
Once the routing filters using TFT reference is set, the mobile node
can refresh the routing filters the same way as described in MEXT-
Jeyatharan & Ng Expires September 3, 2010 [Page 5]
Internet-Draft TFT Reference March 2010
Binding [1]. When the home agent receives a refresh binding update
that contains a FID that refers to a TFT reference, the home agent
should re-generate the routing filters from the referenced TFT in
case there is modification in the TFT.
4.3. Modification of TFTs
Modification of TFT can happen when a new packet filter is added to a
TFT associated with an EPS bearer, or a packet filter is removed from
a TFT associated with an EPS bearer. When the mobile node detects
such a modification, it can perform a refresh operation by sending a
BU message containing a FID option which refers to the modified TFT.
When the home agent receives a refresh binding update that contains a
FID that refers to a TFT reference, the home agent should re-generate
the routing filters from the referenced TFT.
4.4. Removal of TFTs
TFT may be removed when the EPS bearer is torn down, or simply de-
associated from the EPS bearer. When the mobile node detects the
removal of a TFT, it should send a BU message to remove the FID that
previously referred to this TFT. This follows the same filter
deletion operation as specified in MEXT-Binding [1].
5. Modification to Existing Protocol
A new traffic selector extension to the flow binding process
described in MEXT-Binding [1] is described here. It is in parallel
to binary format traffic selector sub-option [4]. A new TFT
reference traffic selector sub-option is defined.
5.1. TFT Reference Traffic Selector Sub-option Format
The TFT Reference Traffic Selector format is used to carry a
reference to a TFT. It is included in the FID Option of a Binding
Update Mobility Header.
0 1 2 3 4
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-opt Type | Sub-Opt Len | TS Format | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TFT Ref |
+-+-+-+-+-+-+-+-+
Figure 2: TFT Reference Traffic Selector Sub-option
Jeyatharan & Ng Expires September 3, 2010 [Page 6]
Internet-Draft TFT Reference March 2010
Sub-Opt Type
A value of 3 is already assigned in draft MEXT-FlowBinding [1].
Sub-Opt Length
An 8-bit unsigned integer, representing the length in octets of
the TFT reference traffic selector sub-option. This field
indicates the length of the sub-option not including the Sub-opt
Type and Sub-opt Length fields. The value for the Sub-Opt Len
field is 3 for this TFT Reference Traffic Selector Sub-option.
TS Format
An 8-bit unsigned integer indicating the Traffic Selector Format.
Value "0" is reserved and SHOULD NOT be used. The Traffic
Selector value needs to be assigned by IANA.
Reserved
An 8-bit reserved field. It SHOULD be set to zero by the sender
and ignored by the receiver.
TFT Reference
This is an 8 bit field used to carry the EPS bearer ID.
6. Mobile Node Operation
When creating a flow binding BU, the needed mobility options in
passing routing rules to the home agent, format of the BU tied to
ordering of the relevant mobility options and sub-options and
alignment requirement MUST follow the considerations given in MEXT-
FlowBinding [1]. The create, refresh, modification and delete
operations tied to flow filtering MUST follow procedures outlined in
MEXT-FlowBinding [1]. The Binding Acknowledgment to the flow binding
BU MUST be processed as described in MEXT-FlowBinding [1].
When creating flow binding rules whereby the mobile node wants flows
tied to existing TFTs to be sent via 3GPP access or non-3GPP access,
it must use flow binding mechanism whereby, the FID option in the BU
is attached with a TFT reference traffic selector sub-option. The
mobile node MUST set the TFT reference field to the EPS bearer ID for
which the TFT is referred from in the TFT reference traffic selector
sub-option.
Jeyatharan & Ng Expires September 3, 2010 [Page 7]
Internet-Draft TFT Reference March 2010
If there are multiple TFTs (i.e. multiple EPS bearers) to refer from,
the mobile node MUST use a FID option for each TFT and attach a TFT
reference traffic selector sub-option to each such FID option in the
initial flow binding set up procedures. Flow binding for multiple
TFTs can be performed in an individual manner by means of individual
BUs or as a bulk manner as outlined in MEXT-FlowBinding [1].
When a TFT is removed in the 3GPP access, the mobile node MUST send a
delete filter message for the FID linked to the TFT as described in
MEXT-FlowBinding [1].
When a TFT is modified, the mobile node SHOULD send a refresh BU to
request the home agent to re-generate the routing rules from the
referred TFT.
7. Home Agent Operation
The processing of the create, refresh, modify and delete flow binding
update at the home agent will be according to MEXT-FlowBinding [1].
Only when the TFT reference traffic selector sub-option is found in
create state, the home agent will use this option to setup flow
binding rules.
Once the home agent receives and successfully process binding update
message with TFT reference traffic selector sub-option it will create
the flow routing table as disclosed in MEXT-FlowBinding [1]. The
home agent will locate the packet filters in the TFTs referred to by
the TFT reference traffic selector sub-option and install relevant
routing rules based on a one-to-one conversion from each located
Packet Filter. How the home agent can locate the packet filters and
generate routing rules from the packet filters is out of scope of
this document.
8. IANA Considerations
This draft introduces a new value for the traffic selector format
field in the traffic selector sub-option. This new traffic selector
value for the traffic selector format field needs to be assigned by
IANA.
9. Security Considerations
This draft does not need any new security mechanism and the security
mechanism specified in draft MEXT-FlowBinding [1] is adequate to
Jeyatharan & Ng Expires September 3, 2010 [Page 8]
Internet-Draft TFT Reference March 2010
carry the flow binding rules with TFT reference as the new traffic
selector format for the traffic selector sub-option.
10. References
10.1. Normative Reference
[1] Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G., and K.
Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO Basic
Support", draft-ietf-mext-flow-binding-05 (work in progress),
February 2010.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K.
Nagami, "Multiple Care-of Addresses Registration", RFC 5648,
October 2009.
[4] Tsirtsis, G., Giaretta, G., Soliman, H., and N. Montavont,
"Traffic Selectors for Flow Bindings",
draft-ietf-mext-binary-ts-04 (work in progress), February 2010.
[5] "Technical Specification Group Services and System aspects",
3GPP TS 23.401, December 2009.
[6] "Technical Specification Group Core Network and Terminals",
3GPP TS 24.008, December 2009.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative Reference
[8] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[9] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009.
[10] "Technical Specification Group Service and System Aspects",
3GPP TS 23.261, January 2010.
[11] "Technical Specification Group Core Network and Terminals",
3GPP TS 29.274, May 2008.
Jeyatharan & Ng Expires September 3, 2010 [Page 9]
Internet-Draft TFT Reference March 2010
Authors' Addresses
Mohana Dahamayanthi Jeyatharan
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
SG
Phone: +65 65505494
Email: mohana.jeyatharan@sg.panasonic.com
Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
SG
Phone: +65 65505420
Email: chanwah.ng@sg.panasonic.com
Jeyatharan & Ng Expires September 3, 2010 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 15:48:42 |