Network Working Group                                         K. Mitsuya
Internet-Draft                                           Keio University
Expires: April 19, 2007                                        K. Tasaka
                                                            KDDI R&D Lab
                                                             R. Wakikawa
                                                         Keio University
                                                        October 16, 2006


                A Policy Data Set for Flow Distribution
         draft-mitsuya-monami6-flow-distribution-policy-02.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 April 19, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The multiple care-of addresses registration protocol [1] maintains at
   the same time multiple virtual paths with its home agent or
   correspondent nodes.  This document provides a policy data set for
   flow distribution among the multiple paths.  The flow distribution
   policy defines how packets are forwarded from and to the mobile node



Mitsuya, et al.          Expires April 19, 2007                 [Page 1]


Internet-Draft   A Policy Data Set for Flow Distribution    October 2006


   by using the multiple paths.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3

   3.  Architecture Overview  . . . . . . . . . . . . . . . . . . . .  4

   4.  Policy Data Set  . . . . . . . . . . . . . . . . . . . . . . .  5

   5.  Error Codes  . . . . . . . . . . . . . . . . . . . . . . . . .  7

   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8

   7.  Changes from Previous Revisions  . . . . . . . . . . . . . . .  8

   8.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . .  8

   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8

   Appendix A.  Schema Fragment . . . . . . . . . . . . . . . . . . .  9

   Appendix B.  Policy Exchange using HTTP/SOAP . . . . . . . . . . . 10
     B.1.  Request to Install Policy  . . . . . . . . . . . . . . . . 11
     B.2.  Update Policy  . . . . . . . . . . . . . . . . . . . . . . 12
     B.3.  Flush Policy . . . . . . . . . . . . . . . . . . . . . . . 12
     B.4.  Response . . . . . . . . . . . . . . . . . . . . . . . . . 13

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16


















Mitsuya, et al.          Expires April 19, 2007                 [Page 2]


Internet-Draft   A Policy Data Set for Flow Distribution    October 2006


1.  Introduction

   A mobile node (mobile host or router) has several network accesses to
   the Internet and switches between or simultaneously uses these
   interfaces.  Traffic from and to the mobile node are distributed to
   these interfaces based on user's and network's operator policies.

   This document is an informational draft to explain how to utilize
   multiple paths provided by the multiple care-of addresses
   registration protocol [1] to distribute traffic from and to a mobile
   node among the available paths.

   The multiple care-of addresses registration protocol (MCoA) provides
   an extension to Mobile IPv6 in order to maintain at the same time
   multiple virtual paths with its home agent or correspondent nodes.
   An unique identifier named BID (Binding Unique Identification number)
   is assigned on each path to distinguish each of them.  By this way,
   it is possible to register multiple CoAs at the same time.  This
   draft aims to provide a solution to define Flow Distribution Policy,
   how packets are forwarded from and to a mobile node by using its
   multiple CoAs, and to exchange the flow distribution policy between
   the endpoints of the multiple virtual paths.

   Our approach supports the separation of registering bindings and
   exchanging flow distribution policy unlike those proposed protocols
   [4] [5] [6] [7].  The proposed protocols carry the policies in the
   mobility messages.  It is not always 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 a single binding update signaling.  The mobility
   header does not support the fragmentation.  Furthermore, when the
   policy is wrong, because of e.g. duplication of policies, it could be
   required to exchange several mobility message to negotiate a solution
   to the problem.  It is not the purpose of mobility signaling.

   First, this draft explains the overview of our proposed architecture
   to clarify the target of this draft.  Second, this draft provides a
   policy data set for flow distribution.  Additionally, this draft also
   provides an example a dynamic policy exchange method.


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 April 19, 2007                 [Page 3]


Internet-Draft   A Policy Data Set for Flow Distribution    October 2006


3.  Architecture Overview

   The overview of our proposed architecture is shown in Figure 1.
   Multiple virtual paths maintained by the multiple care-of addresses
   registration protocol is shown as IF1, IF2, IF3, and IF4.  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 should have the flow distribution feature.  A
   virtual path between a mobile node and a home agent is achieved with
   the multiple care-of addresses registration protocol and it may be
   abstracted as one of the network interfaces.  Flows are then being
   distributed among the available paths thanks to the polices installed
   on the system with the IPF tool.  What we are missing here is how to
   synchronize the user's and network operator's policy between mobile
   node and home agent.  (A): A policy data set, "Policy" in the figure,
   is an abstracted user policy and a text based data set.  The policy
   data set has to be translated into the format of the IPF system to be
   able to install the policy on a host.  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).

   Note that the installation of the policy data set can be ordered not
   only from MN to HA (or HA to MN) but also is ordered from MNN and CN
   to MN and HA by using a dynamic policy exchange method if security
   associations are established.






Mitsuya, et al.          Expires April 19, 2007                 [Page 4]


Internet-Draft   A Policy Data Set for Flow Distribution    October 2006


4.  Policy Data Set

   The policy includes Home address, Condition, Flow, Action and
   Lifetime.  A set of selectors (Home Address, Condition, and Flow) is
   associated to a target (Action).  Home address is a IPv6 home address
   used as the mobile node identifier.  Policies are defined for each
   condition of the mobile node.  A Condition refers to the kind of
   available network accesses on the mobile node.  With the multiple
   care-of addresses registration protocol, the BID identifies in an
   unique way of the multiple paths between the mobile node and the home
   agent.  Therefore, Condition is a list of available BIDs.  Flow is a
   flow identified with a particular syntax described later in this
   section.  Action defines how the flow is forwarded from and to mobile
   nodes.  Lifetime is the lifetime of the installed policy.

   Policies could be installed on both the mobile node and the home
   agent.  But a mobile node only has the responsibility for out-going
   traffic from the mobile node, and a home agent has the responsibility
   about the traffic going to the mobile node.  It is thus required to
   clarify to where a policy is addressed.  This is the definition of
   Direction in this draft, respectively described as "in" or "out".  A
   flow is identified by the source/destination pair, its direction
   (FROM mobile node "out" or TO mobile node "in"), 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 format for policy data set can be described using the following
   grammar in BNF:

   filter-rule = homeAddr condition flow action lifetime

   homeAddr    = host-name .
   condition   = decnumber .
   flow        = direction [ "quick" ] match .
   action      = "on" decnumber | "drop" .
   lifetime    = decnumber

   direction   = "in" | "out" .
   match       = [ tos ] [ ttl ] [ proto ] [ ip ] .

   tos         = "tos" decnumber | "tos" hexnumber .
   ttl         = "ttl" decnumber .
   proto       = "proto" protocol .
   ip          = srcdst [ flags ] [ with withopt ] [ icmp ] [ keep ] .

   protocol    = "tcp/udp" | "udp" | "tcp" | "icmp" | decnumber .
   srcdst      = "all" | fromto .



Mitsuya, et al.          Expires April 19, 2007                 [Page 5]


Internet-Draft   A Policy Data Set for Flow Distribution    October 2006


   fromto      = "from" object "to" object .

   object      = addr [ port-comp | port-range ] .
   addr        = "any" | nummask | host-name
                                 [ "mask" ipaddr | "mask" hexnumber ] .
   port-comp   = "port" compare port-num .
   port-range  = "port" port-num range port-num
   flags       = "flags" flag { flag } [ "/" flag { flag } ] .
   with        = "with" | "and" .

   nummask     = host-name [ "/" decnumber ] .
   Host-name   = ipaddr | hostname | "any" .
   ipaddr      = host-num ":" host-num ":" host-num ":" host-num ":"
                 host-num ":" host-num ":" host-num ":" host-num .
   host-num    = digit [ digit [ digit ] ] .
   port-num    = service-name | decnumber .

   withopt     = [ "not" | "no" ] opttype [ withopt ] .
   opttype     = "ipopts" | "short" | "frag" | "opt" optname .
   optname     = ipopts [ "," optname ] .
   ipopts      = optlist | "sec-class" [ secname ] .
   secname     = seclvl [ "," secname ] .
   seclvl      = "unclass" | "confid" | "reserv-1" | "reserv-2" |
                 "reserv-3" | "reserv-4" | "secret" | "topsecret" .

   decnumber   = digit [ decnumber ] .
   hexnumber   = "0" "x" hexstring .
   hexstring   = hexdigit [ hexstring ] .

   compare     = "=" | "!=" | "<" | ">" | "<=" | ">=" | "eq" | "ne"|
                 "lt" | "gt" |"le" | "ge" .
   range       = "<>" | "><" .
   hexdigit    = digit | "a" | "b" | "c" | "d" | "e" | "f" .
   digit       = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
                 "8" | "9" .
   flag        = "F" | "S" | "R" | "P" | "A" | "U" .

   For example, a mobile node has a home address, 2001:db8::328.  The
   mobile node has two network accesses and BIDs (11 and 800) are
   assigned to each.  When both interfaces are available, a flow from
   2001:db8::dead:beef is delivered via BID 11.  When only an interface
   which BID is 11 is available, a flow to 2001:db8::dead:beef and port
   = 25 is delivered via BID 800.  In this case, the policy is described
   as below:

   2001:db8::1000 11,800 in src=2001:db8::dead:beef on 11 0
   2001:db8::1000 800 out quick dst=2001:db8::dead:beef port=25 drop 0




Mitsuya, et al.          Expires April 19, 2007                 [Page 6]


Internet-Draft   A Policy Data Set for Flow Distribution    October 2006


   This policy data 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 is manufactured.

   2.  Dynamic-exchange: a policy can be exchange by using any transport
       protocol such as SFTP, HTTPS or any other secured transport
       protocol.

   A dynamic exchange method using SOAP is introduced in Appendix A.


5.  Error Codes

   When a policy data set is exchanged between two hosts, the response
   message needs to be exchanged.  The response message indicates if an
   error is carried by using a transport protocol.  A responder returns
   an error message as the response message to the initiator when a
   responder evaluates that there are some errors in policy data set.
   The error message may include a error code and its detailed message.
   The values are described as follow:

   +-------+------------------+----------------------------------------+
   | 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.          |
   +-------+------------------+----------------------------------------+




Mitsuya, et al.          Expires April 19, 2007                 [Page 7]


Internet-Draft   A Policy Data Set for Flow Distribution    October 2006


                      Table 1: Error code and message


6.  Security Considerations

   The transport layer used to exchange the flow distribution policy
   should be secured by using secured transport protocol such as HTTPS.


7.  Changes from Previous Revisions

   Version 02 change:

   o  Change from the xml-based format to a BNF format.

   Version 01 change:

   o  Clarify the meaning of "Direction".

   o  Add how to specify a range of address or port.

   o  Mention that any nodes can also be Initiator/Responder.


8.  Acknowledgment

   The authors would like to thank Manabu Tsukada and Romain Kuntz for
   their comments.  The authors would also like to thank Shigeyuki
   Akiba, Masatoshi Suzuki and Hiroki Horiuchi for their support and
   assistance.

9.  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.

   [4]  Montavont, N., "Home Agent Filtering for Mobile IPv6",
        draft-montavont-mobileip-ha-filtering-v6-00 (work in progress),
        December 2003.




Mitsuya, et al.          Expires April 19, 2007                 [Page 8]


Internet-Draft   A Policy Data Set for Flow Distribution    October 2006


   [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.


Appendix A.  Schema Fragment

   In this section, a xml based policy data set is described.  The
   schema fragments of a xml based policy data set should be like
   Figure 4.  A policy data set MUST incude homeAddr, condition,
   lifetime and one policy at least.


   <Element name="flowDistributionPolicy"
            type="tns:flowDistributionPolicy">
   <complexType>
     <element name="homeAddr" type="xsd:string" />
     <element name="condition" type="xns:string" />
     <element name="lifetime" 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 4: Flow Distribution Policy




Mitsuya, et al.          Expires April 19, 2007                 [Page 9]


Internet-Draft   A Policy Data Set for Flow Distribution    October 2006


   Figure 5 is an example configuration using the scheme fragment.  In
   the present case, a mobile node has a home address, 2001:db8::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:db8::dead:beef are delivered via BID 11, and flows to 2001:db8::
   dead:beef and port = 25 are delivered via BID 800.

   A port number field and a protocol number field MUST include a
   Regular Expression.  Network address can be included in a soruce
   address or a destination address field as "2001:db8::/64".


   <e:flowDistributionPolicy>
     <homeAddr>2001:db8::328</homeAddr>
     <condition>11,800</condition>
     <lifetime>3600</lifetime>
     <policy>
       <direction>in</direction>
       <srcAddr>2001:db8::dead:beef</srcAddr>
       <dstBID>11</dstBID>
     </policy>
     <policy>
       <direction>out</direction>
       <quick>1</quick>
       <dstAddr>2001:db8::dead:beef</dstAddr>
       <port>25</port>
       <dstBID>800</dstBID>
     </policy>
   </e:flowDistributionPolicy>


   Figure 5: Sample Configuration


Appendix B.  Policy Exchange using HTTP/SOAP

   In this section, a policy exchange method using HTTP/SOAP (Simple
   Object Access Protocol) [3] 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
   sometimes as well as the Home Agent.  In the next sections, we assume
   that MN is the initiator and HA is the responder.





Mitsuya, et al.          Expires April 19, 2007                [Page 10]


Internet-Draft   A Policy Data Set for Flow Distribution    October 2006


B.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 6.  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:db8::328</homeAddr>
     <condition>11,800</condition>
     <lifetime>3600</lifetime>
     <policy>
       <direction>in</direction>
       <srcAddr>2001:db8::dead:beef</srcAddr>
       <dstBID>11</dstBID>
     </policy>
     <policy>
       <direction>out</direction>
       <quick>1</quick>
       <dstAddr>2001:db8::dead:beef</dstAddr>
       <port>25</port>
       <dstBID>800</dstBID>
     </policy>
   </e:flowDistributionPolicy>
       </SOAP-ENV:Body>
   </SOAP-ENV:Envelope>


   Figure 6: Install Policy

   Once a home agent receives the request message, it evaluates the
   policy.  Home agent MUST reply a response message as mentioned in
   Appendix B.4.  By this message, mobile node can understand it the
   request was accepted or rejected, and it the latter case, the reason
   of the error.




Mitsuya, et al.          Expires April 19, 2007                [Page 11]


Internet-Draft   A Policy Data Set for Flow Distribution    October 2006


B.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 7.


   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:db8::328</homeAddr>
     <condition>11,800</condition>
     <lifetime>3600</lifetime>
     <policy>
       <direction>in</direction>
       <srcAddr>2001:db8::dead:beef</srcAddr>
       <dstBID>800</dstBID>
     </policy>
     <policy>
       <direction>out</direction>
       <quick>1</quick>
       <dstAddr>2001:db8::dead:beef</dstAddr>
       <port>25</port>
       <dstBID>11</dstBID>
     </policy>
   </e:flowDistributionPolicy>


   Figure 7: Update Policy

   Once a home agent received the request message, it evaluates the
   policy.  Home agent MUST reply a response message as mentioned in
   Appendix B.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.

B.3.  Flush Policy

   Figure 8 is a request message example to flush policies already



Mitsuya, et al.          Expires April 19, 2007                [Page 12]


Internet-Draft   A Policy Data Set for Flow Distribution    October 2006


   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:db8::328</homeAddr>
     <condition>*</condition>
     <policy></policy>
   </e:flowDistributionPolicy>


   Figure 8: 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.

B.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 9 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>


   Figure 9: Policy Accepted



Mitsuya, et al.          Expires April 19, 2007                [Page 13]


Internet-Draft   A Policy Data Set for Flow Distribution    October 2006


   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.

   A responder returns error message as the response message to the
   initiator when a responder evaluates that error of some sort is in a
   body element.  The error message may be included error code and
   message in the detail element.  The values are described in Table
   Table 1.

   Figure 10 is an example response message when the policy in a request
   message was subject to errors on the responder.


   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 10: Policy Not Accepted











Mitsuya, et al.          Expires April 19, 2007                [Page 14]


Internet-Draft   A Policy Data Set for Flow Distribution    October 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 Ohara
   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 April 19, 2007                [Page 15]


Internet-Draft   A Policy Data Set for Flow Distribution    October 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 April 19, 2007                [Page 16]