Network Working Group K. Mitsuya
Internet-Draft Keio University
Expires: August 30, 2006 K. Tasaka
KDDI R&D Lab
R. Wakikawa
Keio University
February 26, 2006
A Schema Fragment for Flow Distribution
draft-mitsuya-monami6-flow-distribution-policy-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 August 30, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The multiple care-of address registration protocol [1] provides a
framework to maintain multiple virtual paths with its home agents.
But there is no solution to synchronize a policy for flow
distribution on the multiple paths. This document describes a schema
fragment (a xml based data set) to define flow distribution policy.
Mitsuya, et al. Expires August 30, 2006 [Page 1]
Internet-Draft A Schema Fragment for Flow Distribution February 2006
A dynamic policy exchange method using SOAP is also introduced.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4
4. Policy Data Set . . . . . . . . . . . . . . . . . . . . . . . 4
5. Policy Exchange using HTTP/SOAP . . . . . . . . . . . . . . . 6
5.1. Request to Install Policy . . . . . . . . . . . . . . . . 7
5.2. Update Policy . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Flush Policy . . . . . . . . . . . . . . . . . . . . . . . 9
5.4. Response . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Mitsuya, et al. Expires August 30, 2006 [Page 2]
Internet-Draft A Schema Fragment for Flow Distribution February 2006
1. Introduction
Mobile node has several network accesses to the Internet and switches
between or simultaneously uses these interfaces. Traffic are
distributed to the interfaces based on user or network operator's
policies.
The multiple care-of address registration protocol [1] provides a
framework to maintain multiple virtual paths with its home agents or
correspondent nodes at the same time. An unique identifier named BID
(Binding Unique Identification number) is assigned on each path to
distinguish between them.
This document is an informational draft to explain how to utilize
this architecture in order to distribute traffic based on user
policies.
The proposed protocols [4] [5] [6] [7] carry the policy by mobility
signaling. It is not preferable to attach the policy to mobility
messages because of its scalability and complexity. In the case that
there are many policies, it is impossible to carry all of them within
the binding update signaling. The mobility header cannot have any
fragmentation. Furthermore, when the policy is wrong, because of
e.g. duplication of policies, it could be required to exchange
several mobility signaling to negotiate that. It is not the purpose
of mobility signaling.
First, this draft explain the overview of our proposed architecture
to clarify the target of this draft. Second, this draft provides a
xml based data set, a schema fragment for flow distribution within
mobile node, to describe an policy. A flow is identified by
combining its direction (from mobile node or to mobile node), IPv6
source/destination address, source/destination port, flow id, and
protocol number. The destination interface of the flow is specified
by BID. Additionally, this draft also provides a dynamic policy
exchange method. The policy data set can be exchanged by using any
transport protocol such as SFTP, HTTPS or any other transport
protocol. We introduce here an example method using Simple Object
Access Protocol (SOAP) [3].
2. 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 [2].
Mitsuya, et al. Expires August 30, 2006 [Page 3]
Internet-Draft A Schema Fragment for Flow Distribution February 2006
3. Architecture Overview
This document describes a schema fragment (a xml based data set) to
define flow distribution policy with the multiple care-of address
registration protocol. A dynamic policy exchange method using SOAP
is also introduced.
The overview of this proposal based on the multiple care-of address
registration protocol is shown in Figure 1. Multiple virtual paths
shown as IF1, IF2, IF3, and IF4 are maintained by the multiple
care-of address registration protocol. IPF in the figure means OS-
specific flow distribution feature like IPFilter on BSD and Netfilter
on Linux. Flow-A is represented as "***" and Flow-B as "~~~". Other
available but not used virtual paths are represented as "===".
+---- Mobile Node ----+ +---- Home Agent -----+
| +--------+<--------------(B)--------------->+--------+ |
| | Policy | | | | Policy | |
| +---|----+ +---+ IF1==========IF1 +---+ +---|----+ |
| +--(A)-->| I | | | | I |<--(A)-+ |
| | | IF2**********IF2 | | |
| Flow-A*******| P | | | | P |**************** to the
| | | IF3==========IF3 | |~~~~~~~~~~~~~~~~ Internet
| Flow-B~~~~~~~| F | | | | F | |
| +---+ IF4~~~~~~~~~~IF4 +---+ |
+---------------------+ +---------------------+
Figure 1: Flow Distribution Architecture Overview
Any operating system may have the flow distribution feature. A
virtual path between mobile node and home agent may be abstracted as
one of network interfaces. Flows are then being distributed by IPF
as shown in the figure. This can be achieved with the multiple
care-of address registration protocol. What we are missing here is
how to synchronize the user policy between mobile node and home
agent. (A): A xml based data set, "Policy" in the figure, is an
abstracted user policy and it will be encoded when it is installed
into a flow distribution feature. The definition of policy is
described in Section 4. The policy data set can be installed when
the products are shipped or exchanged by using any transport protocol
(B). An example method using Simple Object Access Protocol (SOAP) to
exchange the policy is introduced in Section 5.
4. Policy Data Set
Mitsuya, et al. Expires August 30, 2006 [Page 4]
Internet-Draft A Schema Fragment for Flow Distribution February 2006
In this section, a xml based policy data set is described.
The policy includes Home address, Condition, Direction and Policy.
Home address is used as the mobile node identifier. Policies should
be different according to the conditions of the mobile node, what
kind of network accesses are available. With the multiple care-of
address registration protocol, BID represents a path with home agent.
Therefore, Condition is a list of available BID. Policies could be
installed both the mobile node and the home agent. But a mobile node
has only the responsibility of out-going traffic from the mobile
node, and a home agent has the responsibility about the traffic going
to the mobile node. So that, it is required to clarify to where a
policy is addressed. A flow is identified by combination of source/
destination, its direction (FROM mobile node or TO mobile node),
address, source/destination port, flow type, and protocol number.
The destination interface of the flow is specified by the BID. These
are the policy elements.
The schema fragments of a xml based policy data set should be like
Figure 2.
<element name="flowDistributionPolicy"
type="tns:flowDistributionPolicy">
<complexType>
<element name="homeAddr" type="xsd:string" />
<element name="condition" type="tns:int" />
<element name="policy" type="tns:Policy" />
</complexType>
</e:flowDistributionPolicy>
<element name="policy" base="tns:Policy" />
<complexType>
<element name="direction" type="xsd:string" />
<element name="quick" type="xsd:int" />
<element name="srcAddr" type="xsd:string" />
<element name="dstAddr" type="xsd:string" />
<element name="srcPort" type="xsd:string" />
<element name="dstPort" type="xsd:string" />
<element name="flowType" type="xsd:string" />
<element name="protoNum" type="xsd:string" />
<element name="dstBID" type="xsd:int" />
</complexType>
</e:policy>
Figure 2: Flow Distribution Policy
Mitsuya, et al. Expires August 30, 2006 [Page 5]
Internet-Draft A Schema Fragment for Flow Distribution February 2006
Figure 3 is an example configuration using the scheme fragment. In
the present case, a mobile node has a home address, 2001:200:0:100::
328. The mobile node has two network accesses and a BID (11 and 800)
is assigned to each. When both interfaces are available, flows from
2001:200:0:100::dead:beef are delivered via BID 11, and flows to
2001:200:0:100::dead:beef and port = 25 are delivered via BID 800.
<e:flowDistributionPolicy>
<homeAddr>2001:200:0:100::328</homeAddr>
<condition>11,800</condition>
<policy>
<direction>in</direction>
<srcAddr>2001:200:0:100::dead:beef</srcAddr>
<dstBID>11</dstBID>
</policy>
<policy>
<direction>out</direction>
<quick>1</quick>
<dstAddr>2001:200:0:100::dead:beef</dstAddr>
<port>25</port>
<dstBID>800</dstBID>
</policy>
</e:flowDistributionPolicy>
Figure 3: Sample Configuration
This policy set could be exchanged by using a transport protocol.
There are possible scenarios:
1. Pre-installed: a policy is installed on mobile node and its home
agent when it manufactured.
2. Dynamic-exchange: a policy can be exchange by using any transport
protocol such as SFTP, HTTPS or any other secured transport
protocol.
5. Policy Exchange using HTTP/SOAP
In this section, a policy exchange method using HTTP/SOAP is
explained. The SOAP request parameter to initiate the policy
exchange is provided by HTTP required, and the SOAP response to
handle error processing is provided by HTTP response.
Here Initiator and Responder are introduced. Mobile node or home
agent can be any type of node. Mobile node could be Initiator
Mitsuya, et al. Expires August 30, 2006 [Page 6]
Internet-Draft A Schema Fragment for Flow Distribution February 2006
sometimes as well as the Home Agent. In the next sections, we assume
that MN is the initiator and HA is the responder.
5.1. Request to Install Policy
When mobile node boots up, it sends a request to install its policy
to the home agent. An example HTTP request to install policy is
shown in Figure 4. The timing to send a request is not limited to
when it boots. Mobile node can send the request before it has
expired or it has changed.
POST /PolicyExchange HTTP/1.1
Host: router1.nemo.jp
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Body>
<e:flowDistributionPolicy>
<homeAddr>2001:200:0:100::328</homeAddr>
<condition>11,800</condition>
<lifetime>3600</lifetime>
<policy>
<direction>in</direction>
<srcAddr>2001:200:0:100::dead:beef</srcAddr>
<dstBID>11</dstBID>
</policy>
<policy>
<direction>out</direction>
<quick>1</quick>
<dstAddr>2001:200:0:100::dead:beef</dstAddr>
<port>25</port>
<dstBID>800</dstBID>
</policy>
</e:flowDistributionPolicy>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figure 4: Install Policy
Once a home agent receives the request message, it evaluates the
policy. Home agent MUST reply a response message as mentioned in
Section 5.4. By this message, mobile node can understand it the
Mitsuya, et al. Expires August 30, 2006 [Page 7]
Internet-Draft A Schema Fragment for Flow Distribution February 2006
request was accepted or rejected, and it the latter case, the reason
of the error.
5.2. Update Policy
When the policy has changed, mobile node can send a update message.
It is not mandatory to update all policies at one, only a small set
of policy can be updated. An example HTTP request to update policies
is shown in Figure 5.
POST /PolicyExchange HTTP/1.1
Host: router1.nemo.jp
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Body>
<e:flowDistributionPolicy>
<homeAddr>2001:200:0:100::328</homeAddr>
<condition>11,800</condition>
<lifetime>3600</lifetime>
<policy>
<direction>in</direction>
<srcAddr>2001:200:0:100::dead:beef</srcAddr>
<dstBID>800</dstBID>
</policy>
<policy>
<direction>out</direction>
<quick>1</quick>
<dstAddr>2001:200:0:100::dead:beef</dstAddr>
<port>25</port>
<dstBID>11</dstBID>
</policy>
</e:flowDistributionPolicy>
Figure 5: Update Policy
Once a home agent received the request message, it evaluates the
policy. Home agent MUST reply a response message as mentioned in
Section 5.4. By this message, mobile node can understand if the
request was accepted or rejected, and in the latter case, the reason
of the error.
Mitsuya, et al. Expires August 30, 2006 [Page 8]
Internet-Draft A Schema Fragment for Flow Distribution February 2006
5.3. Flush Policy
Figure 6 is a request message example to flush policies already
installed.
POST /PolicyExchange HTTP/1.1
Host: router1.nemo.jp
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Body>
<e:flowDistributionPolicy>
<homeAddr>2001:200:0:100::328</homeAddr>
<condition>*</condition>
<policy></policy>
</e:flowDistributionPolicy>
Figure 6: De-registration Policy
The asterisk in the condition tag means that this request MUST apply
to all condition. And the policy tag without any policy inside
requests to install null policy. This goes to flush all policies.
5.4. Response
A responder sets the body element to blank in the response message to
indicate that it has successfully processed the request message.
Figure 7 is a response message example when the policy in a request
message is accepted by the responder.
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Body>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Mitsuya, et al. Expires August 30, 2006 [Page 9]
Internet-Draft A Schema Fragment for Flow Distribution February 2006
Figure 7: Policy Accepted
The response message indicates that an error is carried inside a
fault element. This fault element has a faultcode, a faultstring, a
faultactor and a detail field. The faultcode element is used by
software to provide an algorithmic mechanism to identify the fault.
The faultstring element is intended to provide a human readable
explanation of the fault and is not intended for algorithmic
processing. The faultactor element is intended to provide
information about the cause of the fault to happen within the message
path. And The detail element is intended to carry application
specific error information related to the body element.
This document also introduces the following error code and message in
the detail element. The values are described as followed:
+-------+------------------+----------------------------------------+
| Error | Message | Meaning |
| code | | |
+-------+------------------+----------------------------------------+
| 1001 | Administratively | A responder is not permitted to set |
| | prohibited | Flow Distribution Policy by the |
| | | administrator. |
| 1002 | Initiator | Unauthorized initiator can't set Flow |
| | Operation not | Distribution Policy. |
| | permitted | |
| 1003 | Invalid homeAddr | The homeAddr element in a request |
| | | message is invalid. |
| 1004 | Invalid | The condition element in a request |
| | condition | message is invalid. |
| 1005 | Necessary | The necessary elements are not founded |
| | element not | in a request message. |
| | founded | |
| 1006 | Invalid policy | The policy set in a request message is |
| | | invalid. |
| 1007 | Duplicated | The policy set in a request message is |
| | policy | duplicated. |
| 1008 | Parameter not | The parameters in a request message |
| | supported | are supported in a responder. |
+-------+------------------+----------------------------------------+
Values of the status field less than 1001 indicate that name of fault
codes is Server (home agent). Values equal to 1003 or greater than
1002 indicate that name of fault codes is Client (mobile node)
Figure 8 is an example response message when the policy in a request
message was subject to errors on the responder.
Mitsuya, et al. Expires August 30, 2006 [Page 10]
Internet-Draft A Schema Fragment for Flow Distribution February 2006
HTTP/1.1 500 Internal Server Error
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"/>
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring>Server Error</faultstring>
<detail>
<errorcode>1001</errorcode>
</detail>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figure 8: Policy Not Accepted
6. Security Considerations
The transport used to exchange the flow distribution policy SHOULD be
secured. The transport used to exchange the flow distribution policy
should be secured by using secured transport protocol such as HTTPS.
7. Acknowledgment
The authors would like to thank Manabu Tsukada and Romain Kuntz for
their comments. The authors would also like to thank Shigeyuki
Akiba, Tohru Hasegawa and Hiroki Horiuchi for their support and
assistance.
8. References
[1] Wakikawa, R., "Multiple Care-of Addresses Registration",
draft-wakikawa-mobileip-multiplecoa-04 (work in progress),
June 2005.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J., and H.
Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework",
W3C Recommendation REC-soap12-part1-20030624, June 2003.
Mitsuya, et al. Expires August 30, 2006 [Page 11]
Internet-Draft A Schema Fragment for Flow Distribution February 2006
[4] Montavont, N., "Home Agent Filtering for Mobile IPv6",
draft-montavont-mobileip-ha-filtering-v6-00 (work in progress),
December 2003.
[5] Soliman, H., "Flow Movement in Mobile IPv6",
draft-soliman-mobileip-flow-move-03 (work in progress),
June 2003.
[6] Kuladinithi, K., "Filters for Mobile IPv6 Bindings",
draft-nomadv6-mobileip-filters-03 (work in progress),
October 2005.
[7] Wakikawa, R., "Multiple Network Interfaces Support by Policy-
Based Routing on Mobile IPv6", Proceedings the International
Conference on Wireless Networks (ICWN), July 2002.
Mitsuya, et al. Expires August 30, 2006 [Page 12]
Internet-Draft A Schema Fragment for Flow Distribution February 2006
Authors' Addresses
Koshiro Mitsuya
Keio University
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan
Phone: +81 466 49 1100
Email: mitsuya@sfc.wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~mitsuya/
Kazuyuki Tasaka
KDDI R&D Laboratories Inc.
2-1-15 Oohara
Fujimino, Saitama 356-8502
Japan
Phone: +81 49 278 7574
Email: ka-tasaka@kddilabs.jp
Ryuji Wakikawa
Keio University
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan
Phone: +81 466 49 1100
Email: ryuji@sfc.wide.ad.jp
URI: http://www.wakikawa.org/
Mitsuya, et al. Expires August 30, 2006 [Page 13]
Internet-Draft A Schema Fragment for Flow Distribution February 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Mitsuya, et al. Expires August 30, 2006 [Page 14]