MEXT Working Group C. Larsson Internet-Draft M. Eriksson Intended status: Standards Track Ericsson Research Expires: August 28, 2009 K. Mitsuya Keio University K. Tasaka KDDI R&D Lab R. Kuntz Louis Pasteur University February 24, 2009 Flow Distribution Rule Language for Multi-Access Nodes draft-larsson-mext-flow-distribution-rules-02 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 28, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Larsson, et al. Expires August 28, 2009 [Page 1] Internet-Draft Flow Distribution Rule Language February 2009 to this document. Larsson, et al. Expires August 28, 2009 [Page 2] Internet-Draft Flow Distribution Rule Language February 2009 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. 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 August 28, 2009 [Page 3] Internet-Draft Flow Distribution Rule Language February 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 6 2. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9 3. Conceptual Model . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Rule Set Characteristics . . . . . . . . . . . . . . . . 12 3.2. How to generate a PID . . . . . . . . . . . . . . . . . 14 3.3. Storing Routing Rules . . . . . . . . . . . . . . . . . 14 4. Multi-Access Rule Language Overview . . . . . . . . . . . . . 15 4.1. Rule Language Definition . . . . . . . . . . . . . . . . 15 4.2. Lexical Analysis . . . . . . . . . . . . . . . . . . . . 16 4.3. Rule Language Semantic . . . . . . . . . . . . . . . . . 16 5. Rule Set Semantics . . . . . . . . . . . . . . . . . . . . . . 17 5.1. Target Node . . . . . . . . . . . . . . . . . . . . . . 17 5.2. Rules and Path Identifier . . . . . . . . . . . . . . . 17 5.3. Conditional Rule-Sets . . . . . . . . . . . . . . . . . 17 5.4. Local and Peer Node . . . . . . . . . . . . . . . . . . 18 5.5. Any-port . . . . . . . . . . . . . . . . . . . . . . . . 18 5.6. Ranges . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.7. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.8. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.9. Explicit IP Protocol Numbers . . . . . . . . . . . . . . 19 5.10. Any IP Protocol and Flow Labels . . . . . . . . . . . . 20 5.11. Extra clauses . . . . . . . . . . . . . . . . . . . . . 20 5.12. Asymmetric Routing . . . . . . . . . . . . . . . . . . . 20 5.13. Round-robin . . . . . . . . . . . . . . . . . . . . . . 21 5.14. n-casting . . . . . . . . . . . . . . . . . . . . . . . 21 5.15. Mobile Networks . . . . . . . . . . . . . . . . . . . . 21 6. Generating Routing Rules and Bindings . . . . . . . . . . . . 22 6.1. Generating Routing Rules . . . . . . . . . . . . . . . . 22 6.2. Generating Bindings . . . . . . . . . . . . . . . . . . 22 6.3. Sending Routing Rules and Bindings to Peering Nodes . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . 27 Appendix A. Applying the Rule Set to Mobile IPv6 . . . . . . . . 28 A.1. Mapping Between PID and IP Address . . . . . . . . . . . 28 A.2. Mobile IPv6 Example . . . . . . . . . . . . . . . . . . 28 Appendix B. Example of Routing Rules . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Larsson, et al. Expires August 28, 2009 [Page 4] Internet-Draft Flow Distribution Rule Language February 2009 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 node's 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. Recently, some efforts have been dedicated to define IPv4-to-IPv6 transition mechanisms. It is most likely that multi-homed nodes will connect to heterogeneous or dual-stack IP networks, hence the motivation to support both versions of the IP protocol in the definition of the rule language. 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], Mobile IPv4 [RFC3344], HIP [RFC5201], 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 Larsson, et al. Expires August 28, 2009 [Page 5] Internet-Draft Flow Distribution Rule Language February 2009 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. 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 [RFC5201]. 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 Path Identifier (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 [RFC5201]. Routing Proxy A Routing Proxy is a node in the Internet that does routing for the target node and needs to know about the multi-homed node's capability of receiving data on multiple network interfaces. For mobility protocols, this is the Anchor Point, e.g., in case of Mobile IPv6 the Routing Proxy is the Home Agent. Larsson, et al. Expires August 28, 2009 [Page 6] Internet-Draft Flow Distribution Rule Language February 2009 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. 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 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 Larsson, et al. Expires August 28, 2009 [Page 7] Internet-Draft Flow Distribution Rule Language February 2009 implementation have to decide through which care-of address a packet should be routed. Larsson, et al. Expires August 28, 2009 [Page 8] Internet-Draft Flow Distribution Rule Language February 2009 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 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 August 28, 2009 [Page 9] Internet-Draft Flow Distribution Rule Language February 2009 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], MIPv4 [RFC3344], HIP [RFC5201] and MOBIKE [RFC4555]. Larsson, et al. Expires August 28, 2009 [Page 10] Internet-Draft Flow Distribution Rule Language February 2009 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 August 28, 2009 [Page 11] Internet-Draft Flow Distribution Rule Language February 2009 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 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 communication paths, one over interface I1 (identified by PID1) and another one over interface I2 (identified by PID2), 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 August 28, 2009 [Page 12] Internet-Draft Flow Distribution Rule Language February 2009 __----__ ( 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 PIDs PID1 and PID2 maps to I1 and I2, respectively: tcp peer port 80 on PID1 tcp peer port 22 on PID2 udp local port 49724 peer P2 port 56512 on PID2 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 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 August 28, 2009 [Page 13] Internet-Draft Flow Distribution Rule Language February 2009 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 intermediate node and 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 August 28, 2009 [Page 14] Internet-Draft Flow Distribution Rule Language February 2009 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 [RFC5234]. 4.1. Rule Language Definition rule-collection = RULE-SET / 1*(CONDITIONAL-SET) conditional-set = CONDITION RULE-SET condition = "<" NUMLIST ">" rule-set = *(RULE ';') rule = [ AF ] FLOW EXTRA ACTION [ WHERE ] af = "ip4" | "ip6" 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 ] extra =/ [ "tos" NEG-RANGE ] [ "ttl" TTL ] action = "on" (RR-LIST / CAST-LIST) / "drop" where = "at" ("local" / PREFIX) 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 ] addr =/ 1*3DIGIT 3("." 1*3DIGIT) hexseq = HEX4 *(":" HEX4) hex4 = 1*4HEXDIGIT port-spec = "port" NEG-RANGE neg-range = [ NOT ] RANGE not = "!" / "not" / "no" Larsson, et al. Expires August 28, 2009 [Page 15] Internet-Draft Flow Distribution Rule Language February 2009 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. 4.3. Rule Language Semantic The rule language definition presented in section 4.1 may lead to semantic errors though the rule set is syntactically correct: for example, the language definition allows to mix IPv6 addresses with the Type of Service (tos) field in the rule selector, though the IPv6 header does not have such field. Such design highly simplifies the language definition, but mandates sanity checks when implementing a language parser. Larsson, et al. Expires August 28, 2009 [Page 16] Internet-Draft Flow Distribution Rule Language February 2009 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. 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.3. 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: Larsson, et al. Expires August 28, 2009 [Page 17] Internet-Draft Flow Distribution Rule Language February 2009 <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.4. 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 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.5. 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 Larsson, et al. Expires August 28, 2009 [Page 18] Internet-Draft Flow Distribution Rule Language February 2009 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. 5.6. 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.7. 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.8. ICMP ICMP packets can be matched on type and code. 5.9. Explicit IP Protocol Numbers It is possible to match flows on protocol numbers: proto 138-255 drop Larsson, et al. Expires August 28, 2009 [Page 19] Internet-Draft Flow Distribution Rule Language February 2009 This will drop any packets with IP protocol number between 138 and 255. 5.10. 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.11. Extra clauses It is possible to match each packet on a few other things: o The IPv6 header hop limit o The IPv6 header traffic class o Whether some particular extension headers are included o The IPv4 Type of Service field One or more of these checks can be included in each rule. 5.12. 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 Larsson, et al. Expires August 28, 2009 [Page 20] Internet-Draft Flow Distribution Rule Language February 2009 rule, and UDP traffic from 2001:db8::15 to the target node will use PID 22. 5.13. 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.14. 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 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.15. 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 August 28, 2009 [Page 21] Internet-Draft Flow Distribution Rule Language February 2009 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 August 28, 2009 [Page 22] Internet-Draft Flow Distribution Rule Language February 2009 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 August 28, 2009 [Page 23] Internet-Draft Flow Distribution Rule Language February 2009 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 " 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. Larsson, et al. Expires August 28, 2009 [Page 24] Internet-Draft Flow Distribution Rule Language February 2009 8. IANA Considerations This memo includes no request to IANA. Larsson, et al. Expires August 28, 2009 [Page 25] Internet-Draft Flow Distribution Rule Language February 2009 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 August 28, 2009 [Page 26] Internet-Draft Flow Distribution Rule Language February 2009 10. References 10.1. Normative References [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. 10.2. Informative References [I-D.draft-eriksson-mext-mipv6-routing-rules] Eriksson, M., "Mobile IPv6 Flow Routing over Multiple Care-of Addresses", Internet-Document draft-eriksson-mext-mipv6-routing-rules, June 2008. [I-D.ietf-mext-flow-binding] Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo Basic Support", draft-ietf-mext-flow-binding-01 (work in progress), February 2009. [I-D.ietf-monami6-multiplecoa] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-11 (work in progress), January 2009. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [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. [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008. Larsson, et al. Expires August 28, 2009 [Page 27] Internet-Draft Flow Distribution Rule Language February 2009 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 either [I-D.ietf-mext-flow-binding] or [I-D.draft-eriksson-mext-mipv6-routing-rules]. 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) Larsson, et al. Expires August 28, 2009 [Page 28] Internet-Draft Flow Distribution Rule Language February 2009 with two communication paths, one over interface I1 (identified by PID1) and another one over interface I2 (identified by PID2), 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. +----+ | HA | +----+ __----__ | ( Access ) | ( Network ) ___----___ +-----+ +-------+ _ /(__ __) \ ( )--------| CN1 | | I1|_/ ---- \_( ) +-----+ | MN | _( Internet ) | I2|_ __----__ / ( ) +-----+ +-------+ \__ ( Access )_/ (___ ___)--------| CN2 | ( Network ) ---- +-----+ (__ __) ---- In this example 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 Larsson, et al. Expires August 28, 2009 [Page 29] Internet-Draft Flow Distribution Rule Language February 2009 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. 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 either [I-D.ietf-mext-flow-binding] or [I-D.draft-eriksson-mext-mipv6-routing-rules]. 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. Larsson, et al. Expires August 28, 2009 [Page 30] Internet-Draft Flow Distribution Rule Language February 2009 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. 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 August 28, 2009 [Page 31] Internet-Draft Flow Distribution Rule Language February 2009 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 // Rules not matching any address and not having an explicit address // family will match both IPv4 and IPv6 flows Larsson, et al. Expires August 28, 2009 [Page 32] Internet-Draft Flow Distribution Rule Language February 2009 tcp peer port 443 on 11; udp on 12; // These two imply the same thing ip4 tcp port 80 on 12; tcp peer 0.0.0.0/0 port 80 on 12; // These are semantic errors (but syntactically OK) ip4 udp peer 2001:db8::/32 on 10; tcp local 10.12.14.16/17 peer 3ffe:1234::1 port 99 on 10; any peer 3ffe:99::1 ttl 12 on 11; // Drop any previously unmatched IPv4 traffic ip4 any drop; // Put all IPv6 traffic on a particular PID ip6 any on 10; // Extra udp local port 99 hop limit 0-22 on 44 any tclass ! 127 ip6h 12-13 drop Conditional rule sets: // Depending on the active PIDs different rule sets are used <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 Larsson, et al. Expires August 28, 2009 [Page 33] Internet-Draft Flow Distribution Rule Language February 2009 Authors' Addresses Conny Larsson Ericsson Research Isafjordsgatan 14E Stockholm SE-164 80 Sweden Phone: +46 8 404 8458 Email: conny.larsson@ericsson.com Michael Eriksson Ericsson Research Isafjordsgatan 14E Stockholm SE-164 80 Sweden Phone: +46 8 757 5888 Email: michael.eriksson@ericsson.com 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 Larsson, et al. Expires August 28, 2009 [Page 34] Internet-Draft Flow Distribution Rule Language February 2009 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 August 28, 2009 [Page 35]