[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

MEXT Working Group                                            C. Larsson
Internet-Draft                                               M. Eriksson
Intended status: Standards Track                       Ericsson Research
Expires: May 12, 2008                                         K. Mitsuya
                                                         Keio University
                                                               K. Tasaka
                                                            KDDI R&D Lab
                                                                R. Kuntz
                                                Louis Pasteur University
                                                        November 9, 2007


         Flow Distribution Rule Language for Multi-Access Nodes
             draft-larsson-mext-flow-distribution-rules-00

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 May 12, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document defines an OS independent rule language as a mean to
   define and perform per flow path selection for a multi-homed node.



Larsson, et al.           Expires May 12, 2008                  [Page 1]


Internet-Draft       Flow Distribution Rule Language       November 2007


   Per flow path selection is typically needed when there exist multiple
   network interfaces, each with different network characteristics, and
   an application has specific performance requirements for a data flow
   that makes one network interface more suitable than another.

   The flow distribution rule set is used by the node itself but also
   exchanged with other nodes that needs to know about the multi-homed
   node's capability of receiving data on multiple network interfaces.
   This document does not define how the rule set is transferred between
   nodes.









































Larsson, et al.           Expires May 12, 2008                  [Page 2]


Internet-Draft       Flow Distribution Rule Language       November 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
       1.1.  Applicability  . . . . . . . . . . . . . . . . . . . . .  4
       1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Architecture Overview  . . . . . . . . . . . . . . . . . . . .  7
   3.  Conceptual Model . . . . . . . . . . . . . . . . . . . . . . .  9
       3.1.  Rule Set Characteristics . . . . . . . . . . . . . . . . 10
       3.2.  How to generate a PID  . . . . . . . . . . . . . . . . . 12
       3.3.  Storing Routing Rules  . . . . . . . . . . . . . . . . . 12
   4.  Multi-Access Rule Language Overview  . . . . . . . . . . . . . 13
       4.1.  Rule Language Definition . . . . . . . . . . . . . . . . 13
       4.2.  Lexical Analysis . . . . . . . . . . . . . . . . . . . . 14
   5.  Rule Set Semantics . . . . . . . . . . . . . . . . . . . . . . 14
       5.1.  Target Node  . . . . . . . . . . . . . . . . . . . . . . 14
       5.2.  Routing Proxy  . . . . . . . . . . . . . . . . . . . . . 14
       5.3.  Rules and Path Identifier  . . . . . . . . . . . . . . . 15
       5.4.  Conditional Rule-Sets  . . . . . . . . . . . . . . . . . 15
       5.5.  Local and Peer Node  . . . . . . . . . . . . . . . . . . 15
       5.6.  Any-port . . . . . . . . . . . . . . . . . . . . . . . . 16
       5.7.  Ranges . . . . . . . . . . . . . . . . . . . . . . . . . 17
       5.8.  IPsec  . . . . . . . . . . . . . . . . . . . . . . . . . 17
       5.9.  ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . 17
       5.10. Explicit IP Protocol Numbers . . . . . . . . . . . . . . 17
       5.11. Any IP Protocol and Flow Labels  . . . . . . . . . . . . 17
       5.12. Extra clauses  . . . . . . . . . . . . . . . . . . . . . 17
       5.13. Asymmetric Routing . . . . . . . . . . . . . . . . . . . 18
       5.14. Round-robin  . . . . . . . . . . . . . . . . . . . . . . 18
       5.15. n-casting  . . . . . . . . . . . . . . . . . . . . . . . 18
       5.16. Mobile Networks  . . . . . . . . . . . . . . . . . . . . 19
   6.  Generating Routing Rules and Bindings  . . . . . . . . . . . . 20
       6.1.  Generating Routing Rules . . . . . . . . . . . . . . . . 20
       6.2.  Generating Bindings  . . . . . . . . . . . . . . . . . . 20
       6.3.  Sending Routing Rules and Bindings to Peering Nodes  . . 21
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
       10.1. Normative References . . . . . . . . . . . . . . . . . . 23
       10.2. Informative References . . . . . . . . . . . . . . . . . 23
   Appendix A.  Applying the Rule Set to Mobile IPv6  . . . . . . . . 23
       A.1.  Mapping Between PID and IP Address . . . . . . . . . . . 24
       A.2.  Mobile IPv6 Example  . . . . . . . . . . . . . . . . . . 24
   Appendix B.  Example of Routing Rules  . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
   Intellectual Property and Copyright Statements . . . . . . . . . . 31





Larsson, et al.           Expires May 12, 2008                  [Page 3]


Internet-Draft       Flow Distribution Rule Language       November 2007


1.  Introduction

   When a node is equipped with multiple network interfaces or has
   multiple addresses assigned to one network interface, the node is
   said to be multi-homed.  When a multi-homed node establishes a
   session with a peer, there exist several potential communication
   paths between the nodes.  Multiple communication paths between two
   nodes imply that unless all traffic is sent over all links, there
   must exist rules in the multi-homed node that for each packet
   determine which path should be used to transmit the packet.

   This document defines an OS independent rule language as a mean to
   define and perform per flow path selection for a multi-homed node.
   Per flow path selection is typically needed when there exist multiple
   network interfaces, each with different network characteristics, and
   an application has specific performance requirements for a data flow
   that makes one network interface more suitable than another.

   The rule language defined in this document is primarily used by
   multi-homed nodes to describe a set of rules used for per flow path
   selection.  The rule set is also exchanged with other nodes (peers
   and mobility anchor points) that needs to know about the multi-homed
   nodes capability of receiving data on multiple network interfaces.
   The transfer of the rule set to the communicating peers is outside
   the scope of this document.

1.1.  Applicability

   The rule language defined in this document can be applied to both
   stationary and mobile multi-homed nodes.  The rule language is
   agnostic with respect to the particular mobility management mechanism
   used, and could therefore be used for any mobility management
   protocols, e.g., Mobile IPv6 [RFC3775], HIP [I-D.ietf-hip-base], and
   MOBIKE [RFC4555].

   The primary use of the defined rules, as described in this document,
   is to specify to a peer node and a mobility anchor point the separate
   communication paths to be used for multiple flows which pass through
   the mobility anchor point (such as for instance the HA in a Mobile-IP
   context) or originate at the peer, where the different flows have
   different requirements for bandwidth, latency, and QoS (quality of
   service).  We will call the node which the multi-homed node decides
   to exchange traffic with the 'Peer'.

   Another example where using the defined rules may be useful is for a
   moving multi-homed HIP-enabled node, when it has many sessions with
   different QoS requirements towards the same server.  The term 'Peer'
   would refer to the server in this context.



Larsson, et al.           Expires May 12, 2008                  [Page 4]


Internet-Draft       Flow Distribution Rule Language       November 2007


   To identify a mobile node some kind of identity is used.  Some
   examples of an identity is the home address in Mobile IPv6 [RFC3775]
   and the Host Identity Tag (HIT) in HIP [I-D.ietf-hip-base].  We will
   use the term 'Identity Tag' as a name for this node identity.
   Additionally, the multi-homed node would have local interface
   addresses associated with each network interface.  The binding
   between the identity tag and the local interface addresses is handled
   by mechanisms specific to each mobility management protocol (e.g.,
   Mobile IPv6, HIP).

1.2.  Terminology

   This document frequently uses the following terms:

   Binding
             A binding is generally expressed in terms of a relation
             between a PID and a local address.  In the context of
             multi-homed nodes, it is advantageous to define match
             functions and bindings separately to avoid excessive
             overhead, as it is expected that it may be necessary to
             update the bindings much more often than the match
             functions.  Bindings can be updated on a handover to a new
             local address, while the match function does not need to
             change.

   Identity Tag
             The identity tag is the identity at which the multi-homed
             node is addressable.  Some examples of an identity tag are
             the home address in Mobile IPv6 [RFC3775] and the Host
             Identity Tag (HIT) in HIP [I-D.ietf-hip-base].

   Local Node
             In the context of multi-homed nodes, 'local node' refers to
             the node for which the routing rules is aimed for.  E.g.,
             in case of Mobile IPv6 the local node is the Mobile Node.

   Path Identifier (PID)
             A Path Identifier (PID) identifies a path between a multi-
             homed node and its peers.  The PID maps to an interface on
             the multi-homed node, how this is done depends on the
             mobility mechanism.  The PID is defined for the multi-homed
             node, and its uniqueness is guaranteed by associating it
             with the multi-homed node's identity tag.  This procedure
             will ensure that PIDs sent to a peer from different multi-
             homed nodes will not collide.






Larsson, et al.           Expires May 12, 2008                  [Page 5]


Internet-Draft       Flow Distribution Rule Language       November 2007


   Peer Node
             A peer node is any node in the Internet that the multi-
             homed node decides to exchange traffic with.  E.g., in case
             of Mobile IPv6 the peer node is the correspondent node.

   Policy
             In the context of multi-homed nodes, Policy is overall
             information which express preferences and constraints on
             how packets should be forwarded from the multi-homed node
             to the intermediate node and the reverse path and from the
             multi-homed node to the peer node and the reverse path.
             Policy may cover such things as access network preferences,
             user and operator preferences, security restrictions, and
             more.  Application of policy will in many cases result in
             definition of routing rules which implement the policy for
             specific traffic flows.

   Routing Rule
             A routing rule is a rule which specifies that traffic with
             certain characteristics is to be handled in a certain
             manner.  As an example, a routing rule might specify that
             any TCP traffic to or from port 80 should be transmitted on
             a certain path.

             A routing rule can be a selector and a Path Identifier
             (PID).  The selector defines which packets match the
             routing rule.  The PID specifies the path, at a specific
             point in time, which should be used for the matching
             packets.

   Rule Set
             A rule set is a collection of routing rules which is
             associated with a certain decision point in the IP stack,
             such as the point where a multi-access capable Mobile IP
             implementation have to decide through which care-of address
             a packet should be routed.















Larsson, et al.           Expires May 12, 2008                  [Page 6]


Internet-Draft       Flow Distribution Rule Language       November 2007


2.  Architecture Overview

   The term policy (or policies), in the context of multi-homed nodes,
   refers to the overall settings and preferences that govern the
   desired path selection between the multi-homed node and peer nodes.
   The policies would typically include things such as the user's and
   operator's preferences regarding access network technologies based on
   certain characteristics, such as delay, bit error rate, cost of
   usage, reliability, security, available bandwidth, etc.  The
   transmission and use of policies, to compute routing rules or for any
   other use, is out of scope for this document.

   The routing rules, in the context of multi-homed nodes, consists of a
   selector and the path to use when a packet matches the selector.
   This documents defines the rule language used for describing routing
   rules.

   Below are some examples of how routing rules would look like for
   capturing traffic with certain characteristics and route it to
   specific paths:

      // Send HTTP traffic to peer using path 13
      tcp peer port 80 on 13

      // Use traffic class marking
      udp tclass 127 on 14
      any tclass 128-255 on 15

   A peer node would typically be a node in the Internet that the multi-
   homed node decides to exchange traffic with.  E.g., in case of Mobile
   IP the peer node is the correspondent node.  The multi-homed node
   sends routing rules to the peer nodes and intermediate nodes.  An
   example of an intermediate node in case of Mobile IP is the Home
   Agent.

   When an IP packet matches a routing rule, the result is to send it on
   the path specified by the Path Identifier (PID).  When a PID has been
   associated with a local address, and the local address is bound to a
   physical interface, we have a complete specification of which
   physical interface should be used to transmit a specific type of IP
   packet.

   Figure 1 illustrates the conceptual separation for sending policies,
   routing rules and binding information.







Larsson, et al.           Expires May 12, 2008                  [Page 7]


Internet-Draft       Flow Distribution Rule Language       November 2007


        Local Node                                    Peer Node
     +-------------+                               +-------------+
     |             |  Exchange of Policies         |             |
     |             |<----------------------------->|             |
     |             |                               |             |
     |             |  Exchange of Routing rules    |             |
     |             |<----------------------------->|             |
     |             |                               |             |
     |             |  Binding PID <-> IP Address   |             |
     |             |<----------------------------->|             |
     +-------------+                               +-------------+


   Figure 1: Conceptual architecture overview


   The proposed architecture of separating the exchange of policies,
   routing rules and binding information is motivated by the fact that:

   o  The timing of events, which causes changes to the routing rules,
      does not necessarily corresponds to a handover event and vice
      versa.

   o  The routing rule exchange protocol can be used with any mobility
      management protocol, e.g., MIPv6 [RFC3775], HIP
      [I-D.ietf-hip-base] and MOBIKE [RFC4555].

























Larsson, et al.           Expires May 12, 2008                  [Page 8]


Internet-Draft       Flow Distribution Rule Language       November 2007


3.  Conceptual Model

   Figure 2 is a conceptual model of how routing rules and bindings may
   be generated.  The Connection Manager may be implemented in any
   manner consistent with the external behavior described in this
   document.

                             +--------------+
         Policies ---------> |              |
                             |              |
         Events -----------> |              | ---> Routing Rules
                             |  Connection  |
         User/Operator ----> |    Manager   | ---> Bindings
         preferences         |              |
                             |              |
         Access Network  --> |              |
         Characteristics     +--------------+


   Figure 2: Conceptual model of how routing rules and bindings can be
   generated.


   In the context of this document a policy (or policies) is a high
   level information which governs how traffic is sent from/to a multi-
   homed node.  One could think of policies as describing the preferred
   actions that should be taken if certain conditions are fulfilled.
   E.g., a multi-homed node could have a policy that states that if WLAN
   is available then this interface is the preferred interface for
   sending HTTP traffic.  If WLAN is not available then the 3G interface
   is the preferred interface for sending HTTP traffic.

   A policy could be installed at a node prior to delivery and/or it
   could be dynamically updated in run-time.  Typically a node would
   have a set of static policies installed while others are dynamically
   installed when needed.  The transmission, installation and use of
   policies is outside the scope of this document.

   Events could be anything that impact the current view of how
   available resources should be used.  For instance, when a new access
   network becomes available this may cause new bindings to be created
   for the existing set of routing rules.  Events could also utilize the
   current view to create routing rules and bindings.  An example of
   this would be when an application opens a socket, which would
   typically generate new routing rules and bindings.

   Preferences would be the user's and operator's way of impacting how
   different access technologies are used.  One way of controlling this



Larsson, et al.           Expires May 12, 2008                  [Page 9]


Internet-Draft       Flow Distribution Rule Language       November 2007


   could be by the user's subscription.  Subscriptions could be in the
   range of "operator decides everything" to "user decides everything".

   Each access network has certain characteristics, such as loss rate,
   jitter, latency, bandwidth, QoS support, power consumptions etc.,
   which impact the choice of access technology for a service.  Some
   access characteristics are static while other are dynamic, and the
   changes could be viewed as events.

   Policy, events, preferences and access network characteristics are
   examples of input to the Connection Manager, which generates routing
   rules and bindings based on this input.  The specification of the
   Connection Manager is outside the scope of this document.

   The routing rules consists of a selector and the Path Identifier,
   PID, to use when an IP packet matches the selector.  This document
   defines the language used for describing the routing rules.  The
   association between a PID and the actual IP address is called a
   Binding.  The Connection Manager application is responsible for the
   creation of bindings.

3.1.  Rule Set Characteristics

   A collection of routing rules is called a Rule Set, and refers to the
   current mapping of flows on the local node's available access
   networks.  Typically, one common rule set is generated for the local
   node and all the peer nodes which the local node is communicating
   with.  However, the routing rule syntax makes it possible to specify
   a routing rule targeting a specific peer.

   The multi-homed node or a trusted network node could generate the
   routing rules.  The routing rules are defining the routing for a
   specific node (or a specific mobile network).  Since the rule set is
   common for the multi-homed node and its peering nodes, the role of
   the node applying the routing rules is important when interpreting
   the routing rules.  The keyword 'local' means the multi-homed node
   and the keyword 'peer' means the peering nodes.

   Below is an example showing a rule set for a multi-access node (MA)
   with two interfaces, called I1 and I2, connected to two different
   access networks.  The multi-access node is communicating with two
   peering nodes, P1 and P2, both being single-homed.









Larsson, et al.           Expires May 12, 2008                 [Page 10]


Internet-Draft       Flow Distribution Rule Language       November 2007


                      __----__
                     ( Access )
                    (  Network )     ___----___         +----+
        +------+  _ /(__    __) \   (          )--------| P1 |
        |    I1|_/      ----     \_(            )       +----+
        | MA   |                  _(  Internet  )
        |    I2|_     __----__   / (            )       +----+
        +------+ \__ ( Access )_/   (___    ___)--------| P2 |
                    (  Network )        ----            +----+
                     (__    __)
                        ----



   The rule set on the multi-homed node depends on the type of
   communication established with the peers.  In this example the multi-
   homed node has established HTTP, interactive SSH and peer-to-peer
   voice over IP traffic with its peers (P1 and P2).  The FIDs FID1 and
   FID2 maps to I1 and I2, respectively:

      tcp peer port 80 on FID1
      tcp peer port 22 on FID2
      udp local port 49724 peer P2 port 56512 on FID2

   The above rule set is distributed to the peer nodes.  How the rule
   set is transferred to the peering nodes is outside the scope of this
   document.  Whether the whole rule set or a subset of the rule set is
   sent to the peering nodes depends on the transport protocol in use
   and if there is any need for the peer node to have this type of
   knowledge for its communication with the multi-homed node.  If, in
   the above example, the MA node would have established a HTTP session
   with P1 and a HTTP and VoIP session with P2, then P1 would not need
   any routing rules to be able to send the return traffic back to the
   MA.  However, P2 would need to know which communication path to use
   for the different traffic flows.

   The implementation of the actual routing mechanism to match the rule
   selectors and follow the rules is platform dependent.













Larsson, et al.           Expires May 12, 2008                 [Page 11]


Internet-Draft       Flow Distribution Rule Language       November 2007


3.2.  How to generate a PID

   How the Connection Manager generates the PID is outside the scope of
   this document.  For example, one possible way of doing it would be
   for the Connection Manager to assign a unique PID number for all
   traffic requesting the same (or similar) type of service (e.g.,
   bandwidth, bit error rate, latency, etc.).  If the access conditions
   changes, i.e., the Connection Manager receives new input data, new
   bindings would be generated which could change the physical interface
   that an existing PID number is associated with.

   The PID is created by the multi-homed node and its uniqueness is
   guaranteed by associating it with the multi-homed node's identity
   tag.

3.3.  Storing Routing Rules

   How the routing rules are stored, in the mult-home node and in the
   peers, is implementation dependent.  They could be stored in a file
   system in the ASCII form that is described in this document, but they
   could also be stored in, e.g., in-core (binary) data structures.






























Larsson, et al.           Expires May 12, 2008                 [Page 12]


Internet-Draft       Flow Distribution Rule Language       November 2007


4.  Multi-Access Rule Language Overview

   This section defines the syntax used to describe routing rules.  It
   uses the formal syntax Augmented Backus-Naur Form (ABNF) as specified
   in [RFC4234].

4.1.  Rule Language Definition

   rule-collection =  RULE-SET / 1*(CONDITIONAL-SET)
   conditional-set =  CONDITION RULE-SET
   condition       =  "<" NUMLIST ">"

   rule-set        =  *(RULE ';')
   rule            =  FLOW EXTRA ACTION [ "at" ("local" / PREFIX) ]

   flow            =  ("tcp" / "udp") (PORT-ADDR-PAIR / ANY-PORT)
   flow            =/ ("ipsec" / "ah" / "esp") SPI-ADDR-PAIR
   flow            =/ "icmp" [ ICMP-SPEC ] ADDR-PAIR
   flow            =/ "proto" NEG-RANGE ADDR-PAIR
   flow            =/ "any" LABEL-ADDR-PAIR
   extra           =  [ "hoplimit" NEG-RANGE ] [ "tclass" NEG-RANGE ]
                      [ "ip6h" NEG-RANGE ]
   action          =  "on" (RR-LIST / CAST-LIST) / "drop"

   port-addr-pair  =  [ "local" PORT-ADDR ] [ "peer" PORT-ADDR ]
   port-addr       =  [ PREFIX ] PORT-SPEC / PREFIX
   any-port        =  PORT-SPEC ADDR-PAIR
   spi-addr-pair   =  [ "local" SPI-ADDR ] [ "peer" SPI-ADDR ]
   spi-addr        =  [ PREFIX ] "spi" NEG-RANGE / PREFIX
   label-addr-pair =  [ "local" LABEL-ADDR ] [ "peer" LABEL-ADDR ]
   label-addr      =  [ PREFIX ] "label" NEG-RANGE / PREFIX
   addr-pair       =  [ "local" PREFIX ] [ "peer" PREFIX ]
   icmp-spec       =  "type" NEG-RANGE [ "code" NEG-RANGE ]
   rr-list         =  NUMLIST
   cast-list       =  NUMBER 1*("&" NUMBER)

   prefix          =  ADDR [ "/" NUMBER ]
   addr            =  HEXSEQ [ "::" [ HEXSEQ ] ] / "::" [ HEXSEQ ]
   hexseq          =  HEX4 *(":" HEX4)
   hex4            =  1*4HEXDIGIT
   port-spec       =  "port" NEG-RANGE
   neg-range       =  [ NOT ] RANGE
   not             =  "!" / "not" / "no"








Larsson, et al.           Expires May 12, 2008                 [Page 13]


Internet-Draft       Flow Distribution Rule Language       November 2007


   range           =  NUMBER [ "-" NUMBER ]
   numlist         =  NUMBER *("," NUMBER)
   number          =  DEC-NUMBER / HEX-NUMBER
   dec-number      =  1*DIGIT
   hex-number      =  "0x" 1*HEXDIGIT
   hexdigit        =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
   digit           =  %x30-39

4.2.  Lexical Analysis

   The routing rules are free text in ASCII text format.  White space is
   used for token separation.  Allowed white space is Space (ASCII 32),
   Horizontal Tab (ASCII 9), and CRLF (ASCII 13 10).

   Comments are allowed at any place where white space is allowed, and
   will be parsed as white space.  A comment starts with two slashes
   ('/', ASCII 47), and continues to the next CRLF.

   The routing rule language is not line based, but there is a 1024
   octet limitation on the length of lines (including the final CRLF),
   to simplify implementations in memory constrained devices.


5.  Rule Set Semantics

   This section explains how the syntax should be interpreted and the
   motivation for using this specific syntax.

5.1.  Target Node

   The node for which the routing rules are used is called the target
   node.  The Identity Tag of the target node is given out-of-band, when
   the rules are transmitted or installed.  Exactly how this is done
   depends on mobility mechanism used, and is outside the scope of this
   document.

   It is also possible to use the rules for a whole moving network, see
   below.

5.2.  Routing Proxy

   A Routing Proxy is a node that does routing for the target node.  For
   mobility protocols, this is the Anchor Point, such as the Home Agent
   of Mobile IPv6 [RFC3775].

   It is also possible to use the rules for a whole moving network, see
   below.




Larsson, et al.           Expires May 12, 2008                 [Page 14]


Internet-Draft       Flow Distribution Rule Language       November 2007


5.3.  Rules and Path Identifier

   The routing rules will identify packet flows, and result in flows
   being dropped or mapped to a particular Path Identifier, PID.  How
   the PID is then mapped to an actual packet transmission channel
   depends on the mobility management method used, and is outside the
   scope of this document.

   When a packet is routed, the rules are checked sequentially.  The
   first rule that matches the packet is selected.  What happens if no
   rule matches, depends on the mobility mechanism, and is not defined
   here.  If the mobility mechanism supports it, it is suggested that
   the packet will use a default path, otherwise the packet will
   probably have to be dropped.  It is strongly advised that all rule
   sets have a catch-all default rule, and does not depend on the
   behavior for non-matching packets.

5.4.  Conditional Rule-Sets

   For some scenarios, it is useful to install or transmit a collection
   of rule-sets at the same time, and select which one to use depending
   on what PIDs are available.  How the set of available PIDs is
   determined is outside the scope of this document.

   When multiple rule-sets are put in a rule-collection, each rule set
   is conditioned with a list of PIDs that should be available inside
   angle brackets, '<' and '>'.  An example:

      <11,800>
         tcp local port 80 on 800
         any on 11
      <11>
         tcp local port 80 drop
         any on 11

   In the rule collection above, the first rule set will be used when
   both PIDs 11 and 800 are available.  The second rule set will be used
   when only PID 11 is available.  If no condition matches, an empty
   rule set will be used, which implies that all packets are dropped.

5.5.  Local and Peer Node

   It is an explicit design goal of the language that the very same
   rules can be used at all nodes that route traffic to or from the
   target node.  This implies that the flow description does not express
   header source or destination, because they will have to be switched
   depending on the direction of the packet transmission.  To achieve
   direction independence, the keyword 'local' and 'peer' are used to



Larsson, et al.           Expires May 12, 2008                 [Page 15]


Internet-Draft       Flow Distribution Rule Language       November 2007


   refer to the endpoints of the flows.  The target node is referred to
   as 'local', and whatever node the target node is communicating with
   is referred to as 'peer'.  An example:

      tcp peer port 80 on 11

   This rule will send packets from the target node with destination
   port 80 on PID 11, and correspondingly send packets to the target
   node with source port 80 on the same PID.  In practice, this means
   that any TCP traffic on the standard HTTP port to or from web servers
   will be put on PID 11.

5.6.  Any-port

   When using well-known ports, the port number can be used to identify
   the type of traffic.  The port number is normally checked at one of
   the endpoints, 'local' or 'peer'.  In some cases, it doesn't matter
   which endpoint that uses the well-known port, the fact that either
   one does is enough to classify the traffic.  Traffic using a well-
   known port could be handled by two rules together:

      tcp local port 25 peer 2001:db8::1 on 44
      tcp peer 2001:db8::1 port 25 on 44

   The first rule would handle SMTP connections from any port on 2001:
   db8::1 to the Mail Transfer Agent, MTA, at the target node.  The
   second rule would correspondingly handle SMTP connections from any
   port on the target node to the MTA at 2001:db8::1.  Note that the
   rules can not be collapsed like this:

      tcp local port 25 peer 2001:db8::1 port 25 on 44

   This would only match flows using port number 25 at both ends, which
   is normally not the case.

   To avoid the double rules in the common case of traffic
   classification on (well-known) port numbers, the any-port mechanism
   can be used.  When used, it means that at least one of the local and
   peer port number must match.  An example:

      tcp port 25 peer 2001:db8::1 on 44

   This rule would handle any SMTP traffic between the target node and
   2001:db8::1, and has the same meaning as the two rules above have
   together.  Note that the port number is given before any 'local' or
   'peer' clauses.





Larsson, et al.           Expires May 12, 2008                 [Page 16]


Internet-Draft       Flow Distribution Rule Language       November 2007


5.7.  Ranges

   At many places where a number is given, a NEG-RANGE can be used.  It
   is a numerical range, which can be optionally negated.  Some examples
   where ranges are used for port numbers:

      tcp port 49152-65535 on 13
      tcp port not 137-139 on 14

5.8.  IPsec

   IPsec traffic can be recognized as one of the IP protocols AH and
   ESP.  The keyword 'ipsec' is a shortcut for any of AH and ESP.  When
   matching IPsec traffic, the SPI can be used for more specific
   matching:

      esp local spi 1500-1599 on 11
      esp peer 2001:db8::1 spi 444 on 11
      ipsec on 44

5.9.  ICMP

   ICMP packets can be matched on type and code.

5.10.  Explicit IP Protocol Numbers

   It is possible to match flows on protocol numbers:

      proto 138-255 drop

   This will drop any packets with IP protocol number between 138 and
   255.

5.11.  Any IP Protocol and Flow Labels

   If the IP protocol number should not be checked, the 'any' keyword
   can be used.  An 'any' rule allows matching on the IPv6 header flow
   label:

      any peer 2001:db8::1 flow 99 on 15
      any local flow 42 on 15
      any on 17

5.12.  Extra clauses

   It is possible to match each packet on a few other things:





Larsson, et al.           Expires May 12, 2008                 [Page 17]


Internet-Draft       Flow Distribution Rule Language       November 2007


   o  The IPv6 header hop limit

   o  The IPv6 header traffic class

   o  Whether some particular extension headers are included

   One or more of these checks can be included in each rule.

5.13.  Asymmetric Routing

   Asymmetric routing means that the packets of a particular flow is not
   using the same path in both directions.  This can be useful when
   using networks that are intrinsically asymmetric, like satellite
   networks.

   One way to achieve asymmetric routing is to have different rules at
   the target node and at the routing proxy or peers.  In some
   scenarios, it is valuable to have the very same rules at all places
   even in the case of asymmetric routing.  To support this, each rule
   can have an "at" clause.  The "at" clause means that the rule is only
   applicable at that address or prefix.  As a special case, the keyword
   'local' is used to refer to the target node.  An example:

      udp peer 2001:db8::15 on 11 at local
      udp peer 2001:db8::15 on 22

   The first rule will only be applied at the target node, so PID 11
   will be used for UDP traffic from the target node to 2001:db8::15.
   All other nodes (routing proxy or peer nodes) will apply the second
   rule, and UDP traffic from 2001:db8::15 to the target node will use
   PID 22.

5.14.  Round-robin

   For load-sharing purposes, round-robin transmission is supported.  To
   use round-robin, a list of PIDs is given instead of just one:

      udp peer 2001:db8:1c32::/48 port 44100 on 4, 4, 5

   Here, UDP traffic from port 44100 at any node in prefix 2001:db8:
   1c32::/48 will be sent on PIDs 4 and 5.  Two out of three packets
   will go on PID 4, which presumably has twice the bandwidth of PID 5.

5.15.  n-casting

   In some specific cases, like important signaling, it can be useful to
   send the packets on multiple PIDs in parallel.  All type of traffic
   is not suited for n-casting.  For instance, TCP is known to be



Larsson, et al.           Expires May 12, 2008                 [Page 18]


Internet-Draft       Flow Distribution Rule Language       November 2007


   sensitive for re-ordering of packets and n-casting may cause TCP slow
   start.  However, the routing rules provides a mechanism to handle
   transport protocols differently, which would make it possible to use
   n-casting for, e.g., some UDP traffic:

      udp peer port 5060 on 11 & 800

   This would transfer UDP packets to and from peer port 5060 on both
   PID 11 and PID 800.

5.16.  Mobile Networks

   A set of rules can be used for an entire moving network.  By default,
   'local' will then refer to all the nodes of the mobile network.  When
   a particular MNN (or set of MNNs) needs special routing, an address
   or prefix can be used after 'local'.  An example:

      udp local 2001:db8::19 port 5600 on 18
      udp local port 5600 on 19

   The first rule will give special treatment to the MNN 2001:db8::19,
   all other MNNs will be handled by the second rule.





























Larsson, et al.           Expires May 12, 2008                 [Page 19]


Internet-Draft       Flow Distribution Rule Language       November 2007


6.  Generating Routing Rules and Bindings

   This section describes when and how routing rules and bindings are
   generated and sent from the local node to the intermediate and
   peering nodes.

6.1.  Generating Routing Rules

   Routing rules could be generated either by the multi-homed node
   itself or by a trusted network node on behalf of the multi-homed
   node.  The multi-homed node is an obvious candidate for generating
   routing rules and bindings since it's aware of all the information
   needed by the Connection Manager.  It would also be able to react
   instantly whenever an event occurs that requires an immediate action.
   However, there may be situations when a trusted network node could
   generate some or all routing rules and bindings.  If everything is
   generated by this node additional communication between the multi-
   homed node and this trusted network node would be required.  The
   actual implementation of this is outside the scope of this document.

   The frequency at which the routing rules are generated is an
   implementation issue.  Depending on the target node type, the
   Connection Manager may generate the whole set of routing rules as the
   node is initiated or it could prefer to have a more dynamic approach
   and generate the routing rules on demand as the node initiate
   applications.

   In case of a static approach the required routing rules exists once
   the multi-homed node has been initiated and it's assumed that they
   will change with a low frequency.

   In case of a dynamic approach there are several events that may
   trigger the creation of a new routing rule.  For example when an
   application requests to open a socket the Connection Manager
   application would create a new routing rule with an associated PID
   number.  As the user starts different applications, the rule set will
   expand and there will be multiple routing rules, each of one
   targeting a specific data flow, with information of how the multi-
   homed node prefer inbound and outbound traffic to be routed.  The
   rule set is dynamic in the sense that if an application is terminated
   then associated routing rules are removed.

6.2.  Generating Bindings

   The Binding is a mapping between the PID and a physical IP address.
   How this mapping is done depends on the mobility mechanism in use and
   is outside the scope of this document.  The syntax defines a selector
   which is associated with a PID.



Larsson, et al.           Expires May 12, 2008                 [Page 20]


Internet-Draft       Flow Distribution Rule Language       November 2007


   There are several events that may trigger the creation of a new
   binding.  For example when an interface becomes available or is
   deactivated, or when the signal strength goes below a certain
   threshold value, etc.  All these events are input to the Connection
   Manager that evaluates it, based on certain criteria that have been
   defined by the user and/or operator, and generates a new set of
   bindings that reflects the current status of the multi-homed node's
   communication capacity.

6.3.  Sending Routing Rules and Bindings to Peering Nodes

   When a new routing rule or a binding has been created, this
   information must be sent to the intermediate and peering nodes to
   make sure that these nodes knows which destination address to use if
   there exist multiple addresses associated with the multi-homed node's
   identity tag.

   Whether the entire rule set or a subset of it is sent to a peering
   node depends on the transport protocol in use and is outside the
   scope of this document.































Larsson, et al.           Expires May 12, 2008                 [Page 21]


Internet-Draft       Flow Distribution Rule Language       November 2007


7.  Security Considerations

   This document specifies a language and not a protocol.  Hence, there
   are no inherent security issues related to this specification.

   However, when the routing rules and bindings are distributed and
   installed, authentication and authorization must be ensured.  Exactly
   how this is done is outside the scope of this document.
   Additionally, the address scope of the routing rules (in particular
   rules using "local <prefix>" clauses) must be checked, to not include
   addresses outside the allowed range.  Failure to do these checks can
   make it possible to do unauthorized routing changes for network
   traffic to other hosts.


8.  IANA Considerations

   This memo includes no request to IANA.


9.  Acknowledgements

   We would like to thank (in alphabetic order) Tero Kauppinen, Henrik
   Levkowetz, Heikki Mahkonen, and Ryuji Wakikawa for their comments and
   suggestions on this work.


























Larsson, et al.           Expires May 12, 2008                 [Page 22]


Internet-Draft       Flow Distribution Rule Language       November 2007


10.  References

10.1.  Normative References

   [RFC4234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

10.2.  Informative References

   [I-D.draft-soliman-monami6-flow-binding]
              Soliman, H., "Flow Bindings in Mobile IPv6 and Nemo Basic
              Support",
              Internet-Document draft-soliman-monami6-flow-binding,
              February 2007.

   [I-D.ietf-hip-base]
              Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
              "Host Identity Protocol", draft-ietf-hip-base-10 (work in
              progress), October 2007.

   [I-D.ietf-monami6-multiplecoa]
              Wakikawa, R., "Multiple Care-of Addresses Registration",
              draft-ietf-monami6-multiplecoa-03 (work in progress),
              July 2007.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC4555]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol
              (MOBIKE)", RFC 4555, June 2006.


Appendix A.  Applying the Rule Set to Mobile IPv6

   This appendix draws examples on how to use routing rules with Mobile
   IPv6 [RFC3775].  Other mobility management protocols would need to
   write separate documents to outline how the routing rules are used
   with that specific mobility management protocol.

   The multiple care-of registration protocol
   [I-D.ietf-monami6-multiplecoa] defines a way to maintain multiple
   paths between two nodes.  However, both communicating nodes must have
   routing rules to know how to distribute traffic flows between the
   different paths.  There may be different ways of distributing the
   routing rules.  In case of Mobile IPv6 this could be done as defined
   in [I-D.draft-soliman-monami6-flow-binding].





Larsson, et al.           Expires May 12, 2008                 [Page 23]


Internet-Draft       Flow Distribution Rule Language       November 2007


A.1.  Mapping Between PID and IP Address

   In the conceptual model, the output from the Connection Manager is
   Bindings.  The binding is the actual mapping between the PID and the
   physical IP address.  By using a PID in the routing rules, a dynamic
   binding between the PID in the routing rule and the actual physical
   interface is achieved.  In case of Mobile IPv6 the physical IP
   address is a MIP care-of address.

   The base Mobile IPv6 [RFC3775] specification only supports that one
   Care-of Address (CoA) is bound to the Home Address (HoA).  To achieve
   simultaneous multi-access, the base protocol needs extensions and
   document [I-D.ietf-monami6-multiplecoa] defines how to register
   multiple care-of addresses bound to a single Home Address.  For doing
   so, a new Binding Unique Identification Number (BID) is carried in
   each binding for the receiver to distinguish between the bindings
   corresponding to the same Home Address.

   The Connection Manager creates routing rules with the associated PID
   and the binding between the PID, BID and care-of address as
   illustrated below.

      Routing Rule: PID -----> BID -----> CoA


   In case of Mobile IPv6 the PID would typically be the BID, i.e.,
   there is no need for an explicit additional mapping.

A.2.  Mobile IPv6 Example

   This example is an extension of the example given in Chapter 4 and
   shows how it can be applied to Mobile IPv6.  The Mobile Node (MN) has
   two interfaces, I1 and I2, connected to two different foreign access
   networks.  The MN is communicating with two Correspondent Nodes, CN1
   and CN2, either directly if Route Optimization is used or via the
   Home Agent (HA) if reverse tunneling is used.  The IPv6 address
   assigned to CN2 is 2001:db8:1411::24.  Both CN1 and CN2 are single-
   homed.













Larsson, et al.           Expires May 12, 2008                 [Page 24]


Internet-Draft       Flow Distribution Rule Language       November 2007


                                       +----+
                                       | HA |
                                       +----+
                      __----__            |
                     ( Access )           |
                    (  Network )     ___----___         +-----+
       +-------+  _ /(__    __) \   (          )--------| CN1 |
       |     I1|_/      ----     \_(            )       +-----+
       |  MN   |                  _(  Internet  )
       |     I2|_     __----__   / (            )       +-----+
       +-------+ \__ ( Access )_/   (___    ___)--------| CN2 |
                    (  Network )        ----            +-----+
                     (__    __)
                        ----



   In this example the Connection Manager is located in the MN, but it
   could also be located in a trusted network node.  The exact location
   of the Connection Manager is a deployment decision.  The Connection
   Manager receives different input events, some of them causing new
   routing rules and bindings to be created.  We assume the following
   scenario:

   o  The MN connects interface I1 to a Wide Area Network (WAN) and
      interface I2 to a Wireless LAN (WLAN) network.  From the MN point
      of view both access networks are foreign networks.

   o  As the MN connects to the access network this will trigger the
      Connection Manager to generate a binding.  For interface I1, BID1
      is assigned number 800, and for interface I2, BID2 is assigned
      number 11.  In addition, BID1 is mapped to CoA1, which has been
      assigned to interface I1 and BID2 is mapped to CoA2, which has
      been assigned to interface I2.  How this mapping is achieved is
      outside the scope of this specification.

   o  According to [I-D.ietf-monami6-multiplecoa] the newly created
      bindings are sent to the HA where a Binding Cache entry for the
      MN's HoA and CoA1 and CoA2 is created.

   o  Now the user at the MN decides to establish a HTTP session towards
      CN1 and at the same time call a friend that can be reached at CN2.
      These events (applications open sockets) are input to the
      Connection Manager and as a result a set of routing rules are
      created that reflects the current view of the MN on how these
      traffic flows should be routed.  In this example the Connection
      Manager has decided to put HTTP traffic on interface I2 and the
      voice traffic on interface I1.



Larsson, et al.           Expires May 12, 2008                 [Page 25]


Internet-Draft       Flow Distribution Rule Language       November 2007


      tcp peer port 80 on 11
      udp local port 49724 peer 2001:db8:1411::24 port 56512 on 800

   o  These routing rules will ensure that outgoing traffic from the MN
      is sent to the correct interface, but to also ensure that incoming
      traffic towards the MN is routed through the correct interface the
      HA also needs access to the MN's routing rules.  Hence, the MN
      will send the newly created routing rules to the HA.  In case of
      Mobile IPv6 this could be done as defined in
      [I-D.draft-soliman-monami6-flow-binding].

   o  Whether the above routing rules also must be sent to the
      correspondent nodes depends on if the MN will do route
      optimization towards the CN and if the MN decides to register
      multiple CoAs with its HoA.  If this is the case, then the CN will
      also need the routing information to able to make the correct
      choice of CoA for the traffic sent towards the MN.

   The routing rules in this example would be interpreted differently by
   the MN and the HA/CN.  In case of the MN it would "send HTTP traffic
   with destination port 80 using CoA2 as source address" and "send
   voice over IP traffic with source port 49724 and destination port
   56512 to node 2001:db8:1411::24 using CoA1 as source address".  The
   HA and the correspondent node(s) would "send HTTP traffic with source
   port 80 using CoA2 as destination address" and "send voice over IP
   traffic with source port 56512 and destination port 49724 using CoA1
   as destination address".

A.2.1.  Creating new Routing Rules

   New routing rules are typically created when an application opens a
   new socket.  If the mobile node user decides to launch a remote login
   session towards CN2 the Connection Manager creates a new routing rule
   and decides that this traffic flow should use interface I1.  After
   this event the rule set at the MN will be as shown below:

      tcp peer port 80 on 11
      udp local port 49724 peer 2001:db8:1411::24 port 56512 on 800
      tcp peer port 22 on 800

   The new routing rules must be sent to the HA and optionally to CN2.
   If for instance the MN user, during the conversation with the CN2
   user, gets the possibility to look at some pictures stored at CN2's
   computer by using HTTP, then CN2 must be aware of the MN's routing
   rules to be able to perform an optimized route selection.  The latter
   assumes that the MN and CN2 route optimize the traffic sent between
   them.




Larsson, et al.           Expires May 12, 2008                 [Page 26]


Internet-Draft       Flow Distribution Rule Language       November 2007


A.2.2.  Route Update

   If a new interface becomes available or an existing interface becomes
   unavailable for some reason, the Connection Manager is notified about
   this event and updates the routing rules and the bindings
   accordingly.  In this example, if the WLAN (interface I2) access gets
   out of range the new rule set would look like below:

      tcp peer port 80 on 800
      udp local port 49724 peer 2001:db8:1411::24 port 56512 on 800
      tcp peer port 22 on 800

   Since there is only one interface available at the mobile node, a de-
   registration of CoA2 and removal of routing rules is needed on the HA
   and the correspondent nodes that has the old information stored.




































Larsson, et al.           Expires May 12, 2008                 [Page 27]


Internet-Draft       Flow Distribution Rule Language       November 2007


Appendix B.  Example of Routing Rules

   This appendix includes a collection of routing rules giving examples
   of how the routing rules can be used to give a feeling for the
   language.

     Some Generic stuff:
     // 6BONE is dead
     any peer 3ffe::/16 drop

     // Put SSH traffic on low-latency link (uses "any-port")
     tcp port 22 on 12

     // HTTP is bulk (we don't have web server, so only match peer port)
     tcp peer port 80 on 13

     // Impress people with short ping times
     icmp type 128-129 on 12

     // Load share rtp (channel 4 is twice as fast as 5)
     udp peer 2001:db8:1c32::/48 port 6900 on 4, 4, 5

     // IPSec is asymmetric (SPIs don't match)
     ipsec local spi 12 on 18
     ipsec peer 2001:db8:8142:500::3775 spi 32 on 18
     ipsec on 19

     // Some links might be eavesdropped (23 is open, 22 is protected)
     esp on 23
     tcp port 443 on 23
     any on 22

     // Bi-cast important traffic
     udp peer port 5060 on 11 & 800

     // Route on flow label
     any local label 4711 on 19
     any peer 2001:db8::55 label 99 on 19

     // Use traffic class marking
     udp tclass 127 on 15
     any tclass 128-255 on 14

     // Use explicit protocol number
     proto 77 on 19

     // Extra
     udp local port 99 hop limit 0-22 on 44



Larsson, et al.           Expires May 12, 2008                 [Page 28]


Internet-Draft       Flow Distribution Rule Language       November 2007


     any tclass ! 127 ip6h 12-13 drop


     Conditional rule sets:
     <11,800>
        tcp local port 80 on 800
        any on 11
     <11>
        tcp local port 80 drop
        any on 11


     Asymmetric routing:
     // Send tcp on 19 on uplink, 22 on downlink
     tcp on 19 at local
     tcp on 22


     Mobile networks:
     // MNN 2001:db8::77 gets special treatment
     udp local 2001:db8::77 port 4400 on 19
     udp local port 4400 on 22


Authors' Addresses

   Conny Larsson
   Ericsson Research
   Torshamnsgatan 23
   Stockholm  SE-164 80
   Sweden

   Phone: +46 8 404 8458
   Email: conny.larsson@ericsson.com


   Michael Eriksson
   Ericsson Research
   Torshamnsgatan 23
   Stockholm  SE-164 80
   Sweden

   Phone: +46 8 757 5888
   Email: michael.eriksson@ericsson.com







Larsson, et al.           Expires May 12, 2008                 [Page 29]


Internet-Draft       Flow Distribution Rule Language       November 2007


   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


   Romain Kuntz
   Louis Pasteur University / LSIIT
   Strasbourg
   France

   Phone: +33 390 244 584
   Email: kuntz@lsiit.u-strasbg.fr
   URI:   http://clarinet.u-strasbg.fr/~kuntz/






















Larsson, et al.           Expires May 12, 2008                 [Page 30]


Internet-Draft       Flow Distribution Rule Language       November 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Larsson, et al.           Expires May 12, 2008                 [Page 31]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/