idnits 2.17.1 draft-larsson-mext-flow-distribution-rules-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 24, 2009) is 5533 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-mext-flow-binding-01 == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-11 -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT Working Group C. Larsson 3 Internet-Draft M. Eriksson 4 Intended status: Standards Track Ericsson Research 5 Expires: August 28, 2009 K. Mitsuya 6 Keio University 7 K. Tasaka 8 KDDI R&D Lab 9 R. Kuntz 10 Louis Pasteur University 11 February 24, 2009 13 Flow Distribution Rule Language for Multi-Access Nodes 14 draft-larsson-mext-flow-distribution-rules-02 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 28, 2009. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. 51 Abstract 53 This document defines an OS independent rule language as a mean to 54 define and perform per flow path selection for a multi-homed node. 55 Per flow path selection is typically needed when there exist multiple 56 network interfaces, each with different network characteristics, and 57 an application has specific performance requirements for a data flow 58 that makes one network interface more suitable than another. 60 The flow distribution rule set is used by the node itself but also 61 exchanged with other nodes that needs to know about the multi-homed 62 node's capability of receiving data on multiple network interfaces. 63 This document does not define how the rule set is transferred between 64 nodes. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . 5 70 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 6 71 2. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9 72 3. Conceptual Model . . . . . . . . . . . . . . . . . . . . . . . 11 73 3.1. Rule Set Characteristics . . . . . . . . . . . . . . . . 12 74 3.2. How to generate a PID . . . . . . . . . . . . . . . . . 14 75 3.3. Storing Routing Rules . . . . . . . . . . . . . . . . . 14 76 4. Multi-Access Rule Language Overview . . . . . . . . . . . . . 15 77 4.1. Rule Language Definition . . . . . . . . . . . . . . . . 15 78 4.2. Lexical Analysis . . . . . . . . . . . . . . . . . . . . 16 79 4.3. Rule Language Semantic . . . . . . . . . . . . . . . . . 16 80 5. Rule Set Semantics . . . . . . . . . . . . . . . . . . . . . . 17 81 5.1. Target Node . . . . . . . . . . . . . . . . . . . . . . 17 82 5.2. Rules and Path Identifier . . . . . . . . . . . . . . . 17 83 5.3. Conditional Rule-Sets . . . . . . . . . . . . . . . . . 17 84 5.4. Local and Peer Node . . . . . . . . . . . . . . . . . . 18 85 5.5. Any-port . . . . . . . . . . . . . . . . . . . . . . . . 18 86 5.6. Ranges . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 5.7. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 5.8. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 5.9. Explicit IP Protocol Numbers . . . . . . . . . . . . . . 19 90 5.10. Any IP Protocol and Flow Labels . . . . . . . . . . . . 20 91 5.11. Extra clauses . . . . . . . . . . . . . . . . . . . . . 20 92 5.12. Asymmetric Routing . . . . . . . . . . . . . . . . . . . 20 93 5.13. Round-robin . . . . . . . . . . . . . . . . . . . . . . 21 94 5.14. n-casting . . . . . . . . . . . . . . . . . . . . . . . 21 95 5.15. Mobile Networks . . . . . . . . . . . . . . . . . . . . 21 96 6. Generating Routing Rules and Bindings . . . . . . . . . . . . 22 97 6.1. Generating Routing Rules . . . . . . . . . . . . . . . . 22 98 6.2. Generating Bindings . . . . . . . . . . . . . . . . . . 22 99 6.3. Sending Routing Rules and Bindings to Peering Nodes . . 23 100 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 101 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 102 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 103 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 104 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 105 10.2. Informative References . . . . . . . . . . . . . . . . . 27 106 Appendix A. Applying the Rule Set to Mobile IPv6 . . . . . . . . 28 107 A.1. Mapping Between PID and IP Address . . . . . . . . . . . 28 108 A.2. Mobile IPv6 Example . . . . . . . . . . . . . . . . . . 28 109 Appendix B. Example of Routing Rules . . . . . . . . . . . . . . 32 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 112 1. Introduction 114 When a node is equipped with multiple network interfaces or has 115 multiple addresses assigned to one network interface, the node is 116 said to be multi-homed. When a multi-homed node establishes a 117 session with a peer, there exist several potential communication 118 paths between the nodes. Multiple communication paths between two 119 nodes imply that unless all traffic is sent over all links, there 120 must exist rules in the multi-homed node that for each packet 121 determine which path should be used to transmit the packet. 123 This document defines an OS independent rule language as a mean to 124 define and perform per flow path selection for a multi-homed node. 125 Per flow path selection is typically needed when there exist multiple 126 network interfaces, each with different network characteristics, and 127 an application has specific performance requirements for a data flow 128 that makes one network interface more suitable than another. 130 The rule language defined in this document is primarily used by 131 multi-homed nodes to describe a set of rules used for per flow path 132 selection. The rule set is also exchanged with other nodes (peers 133 and mobility anchor points) that needs to know about the multi-homed 134 node's capability of receiving data on multiple network interfaces. 135 The transfer of the rule set to the communicating peers is outside 136 the scope of this document. 138 Recently, some efforts have been dedicated to define IPv4-to-IPv6 139 transition mechanisms. It is most likely that multi-homed nodes will 140 connect to heterogeneous or dual-stack IP networks, hence the 141 motivation to support both versions of the IP protocol in the 142 definition of the rule language. 144 1.1. Applicability 146 The rule language defined in this document can be applied to both 147 stationary and mobile multi-homed nodes. The rule language is 148 agnostic with respect to the particular mobility management mechanism 149 used, and could therefore be used for any mobility management 150 protocols, e.g., Mobile IPv6 [RFC3775], Mobile IPv4 [RFC3344], HIP 151 [RFC5201], and MOBIKE [RFC4555]. 153 The primary use of the defined rules, as described in this document, 154 is to specify to a peer node and a mobility anchor point the separate 155 communication paths to be used for multiple flows which pass through 156 the mobility anchor point (such as for instance the HA in a Mobile-IP 157 context) or originate at the peer, where the different flows have 158 different requirements for bandwidth, latency, and QoS (quality of 159 service). We will call the node which the multi-homed node decides 160 to exchange traffic with the 'Peer'. 162 Another example where using the defined rules may be useful is for a 163 moving multi-homed HIP-enabled node, when it has many sessions with 164 different QoS requirements towards the same server. The term 'Peer' 165 would refer to the server in this context. 167 To identify a mobile node some kind of identity is used. Some 168 examples of an identity is the home address in Mobile IPv6 [RFC3775] 169 and the Host Identity Tag (HIT) in HIP [RFC5201]. We will use the 170 term 'Identity Tag' as a name for this node identity. Additionally, 171 the multi-homed node would have local interface addresses associated 172 with each network interface. The binding between the identity tag 173 and the local interface addresses is handled by mechanisms specific 174 to each mobility management protocol (e.g., Mobile IPv6, HIP). 176 1.2. Terminology 178 This document frequently uses the following terms: 180 Binding 181 A binding is generally expressed in terms of a relation 182 between a Path Identifier (PID) and a local address. In 183 the context of multi-homed nodes, it is advantageous to 184 define match functions and bindings separately to avoid 185 excessive overhead, as it is expected that it may be 186 necessary to update the bindings much more often than the 187 match functions. Bindings can be updated on a handover to 188 a new local address, while the match function does not need 189 to change. 191 Identity Tag 192 The identity tag is the identity at which the multi-homed 193 node is addressable. Some examples of an identity tag are 194 the home address in Mobile IPv6 [RFC3775] and the Host 195 Identity Tag (HIT) in HIP [RFC5201]. 197 Routing Proxy 198 A Routing Proxy is a node in the Internet that does routing 199 for the target node and needs to know about the multi-homed 200 node's capability of receiving data on multiple network 201 interfaces. For mobility protocols, this is the Anchor 202 Point, e.g., in case of Mobile IPv6 the Routing Proxy is 203 the Home Agent. 205 Local Node 206 In the context of multi-homed nodes, 'local node' refers to 207 the node for which the routing rules is aimed for. E.g., 208 in case of Mobile IPv6 the local node is the Mobile Node. 210 Path Identifier (PID) 211 A Path Identifier (PID) identifies a path between a multi- 212 homed node and its peers. The PID maps to an interface on 213 the multi-homed node, how this is done depends on the 214 mobility mechanism. The PID is defined for the multi-homed 215 node, and its uniqueness is guaranteed by associating it 216 with the multi-homed node's identity tag. This procedure 217 will ensure that PIDs sent to a peer from different multi- 218 homed nodes will not collide. 220 Peer Node 221 A peer node is any node in the Internet that the multi- 222 homed node decides to exchange traffic with. E.g., in case 223 of Mobile IPv6 the peer node is the correspondent node. 225 Policy 226 In the context of multi-homed nodes, Policy is overall 227 information which express preferences and constraints on 228 how packets should be forwarded from the multi-homed node 229 to the intermediate node and the reverse path and from the 230 multi-homed node to the peer node and the reverse path. 231 Policy may cover such things as access network preferences, 232 user and operator preferences, security restrictions, and 233 more. Application of policy will in many cases result in 234 definition of routing rules which implement the policy for 235 specific traffic flows. 237 Routing Rule 238 A routing rule is a rule which specifies that traffic with 239 certain characteristics is to be handled in a certain 240 manner. As an example, a routing rule might specify that 241 any TCP traffic to or from port 80 should be transmitted on 242 a certain path. 244 A routing rule can be a selector and a PID. The selector 245 defines which packets match the routing rule. The PID 246 specifies the path, at a specific point in time, which 247 should be used for the matching packets. 249 Rule Set 250 A rule set is a collection of routing rules which is 251 associated with a certain decision point in the IP stack, 252 such as the point where a multi-access capable Mobile IP 253 implementation have to decide through which care-of address 254 a packet should be routed. 256 2. Architecture Overview 258 The term policy (or policies), in the context of multi-homed nodes, 259 refers to the overall settings and preferences that govern the 260 desired path selection between the multi-homed node and peer nodes. 261 The policies would typically include things such as the user's and 262 operator's preferences regarding access network technologies based on 263 certain characteristics, such as delay, bit error rate, cost of 264 usage, reliability, security, available bandwidth, etc. The 265 transmission and use of policies, to compute routing rules or for any 266 other use, is out of scope for this document. 268 The routing rules, in the context of multi-homed nodes, consists of a 269 selector and the path to use when a packet matches the selector. 270 This documents defines the rule language used for describing routing 271 rules. 273 Below are some examples of how routing rules would look like for 274 capturing traffic with certain characteristics and route it to 275 specific paths: 277 // Send HTTP traffic to peer using path 13 278 tcp peer port 80 on 13 280 // Use traffic class marking 281 udp tclass 127 on 14 282 any tclass 128-255 on 15 284 A peer node would typically be a node in the Internet that the multi- 285 homed node decides to exchange traffic with. E.g., in case of Mobile 286 IP the peer node is the correspondent node. The multi-homed node 287 sends routing rules to the peer nodes and intermediate nodes. An 288 example of an intermediate node in case of Mobile IP is the Home 289 Agent. 291 When an IP packet matches a routing rule, the result is to send it on 292 the path specified by the PID. When a PID has been associated with a 293 local address, and the local address is bound to a physical 294 interface, we have a complete specification of which physical 295 interface should be used to transmit a specific type of IP packet. 297 Figure 1 illustrates the conceptual separation for sending policies, 298 routing rules and binding information. 300 Local Node Peer Node 301 +-------------+ +-------------+ 302 | | Exchange of Policies | | 303 | |<----------------------------->| | 304 | | | | 305 | | Exchange of Routing rules | | 306 | |<----------------------------->| | 307 | | | | 308 | | Binding PID <-> IP Address | | 309 | |<----------------------------->| | 310 +-------------+ +-------------+ 312 Figure 1: Conceptual architecture overview 314 The proposed architecture of separating the exchange of policies, 315 routing rules and binding information is motivated by the fact that: 317 o The timing of events, which causes changes to the routing rules, 318 does not necessarily corresponds to a handover event and vice 319 versa. 321 o The routing rule exchange protocol can be used with any mobility 322 management protocol, e.g., MIPv6 [RFC3775], MIPv4 [RFC3344], HIP 323 [RFC5201] and MOBIKE [RFC4555]. 325 3. Conceptual Model 327 Figure 2 is a conceptual model of how routing rules and bindings may 328 be generated. The Connection Manager may be implemented in any 329 manner consistent with the external behavior described in this 330 document. 332 +--------------+ 333 Policies ---------> | | 334 | | 335 Events -----------> | | ---> Routing Rules 336 | Connection | 337 User/Operator ----> | Manager | ---> Bindings 338 preferences | | 339 | | 340 Access Network --> | | 341 Characteristics +--------------+ 343 Figure 2: Conceptual model of how routing rules and bindings can be 344 generated. 346 In the context of this document a policy (or policies) is a high 347 level information which governs how traffic is sent from/to a multi- 348 homed node. One could think of policies as describing the preferred 349 actions that should be taken if certain conditions are fulfilled. 350 E.g., a multi-homed node could have a policy that states that if WLAN 351 is available then this interface is the preferred interface for 352 sending HTTP traffic. If WLAN is not available then the 3G interface 353 is the preferred interface for sending HTTP traffic. 355 A policy could be installed at a node prior to delivery and/or it 356 could be dynamically updated in run-time. Typically a node would 357 have a set of static policies installed while others are dynamically 358 installed when needed. The transmission, installation and use of 359 policies is outside the scope of this document. 361 Events could be anything that impact the current view of how 362 available resources should be used. For instance, when a new access 363 network becomes available this may cause new bindings to be created 364 for the existing set of routing rules. Events could also utilize the 365 current view to create routing rules and bindings. An example of 366 this would be when an application opens a socket, which would 367 typically generate new routing rules and bindings. 369 Preferences would be the user's and operator's way of impacting how 370 different access technologies are used. One way of controlling this 371 could be by the user's subscription. Subscriptions could be in the 372 range of "operator decides everything" to "user decides everything". 374 Each access network has certain characteristics, such as loss rate, 375 jitter, latency, bandwidth, QoS support, power consumptions etc., 376 which impact the choice of access technology for a service. Some 377 access characteristics are static while other are dynamic, and the 378 changes could be viewed as events. 380 Policy, events, preferences and access network characteristics are 381 examples of input to the Connection Manager, which generates routing 382 rules and bindings based on this input. The specification of the 383 Connection Manager is outside the scope of this document. 385 The routing rules consists of a selector and the PID to use when an 386 IP packet matches the selector. This document defines the language 387 used for describing the routing rules. The association between a PID 388 and the actual IP address is called a Binding. The Connection 389 Manager application is responsible for the creation of bindings. 391 3.1. Rule Set Characteristics 393 A collection of routing rules is called a Rule Set, and refers to the 394 current mapping of flows on the local node's available access 395 networks. Typically, one common rule set is generated for the local 396 node and all the peer nodes which the local node is communicating 397 with. However, the routing rule syntax makes it possible to specify 398 a routing rule targeting a specific peer. 400 The multi-homed node or a trusted network node could generate the 401 routing rules. The routing rules are defining the routing for a 402 specific node (or a specific mobile network). Since the rule set is 403 common for the multi-homed node and its peering nodes, the role of 404 the node applying the routing rules is important when interpreting 405 the routing rules. The keyword 'local' means the multi-homed node 406 and the keyword 'peer' means the peering nodes. 408 Below is an example showing a rule set for a multi-access node (MA) 409 with two communication paths, one over interface I1 (identified by 410 PID1) and another one over interface I2 (identified by PID2), 411 connected to two different access networks. The multi-access node is 412 communicating with two peering nodes, P1 and P2, both being single- 413 homed. 415 __----__ 416 ( Access ) 417 ( Network ) ___----___ +----+ 418 +------+ _ /(__ __) \ ( )--------| P1 | 419 | I1|_/ ---- \_( ) +----+ 420 | MA | _( Internet ) 421 | I2|_ __----__ / ( ) +----+ 422 +------+ \__ ( Access )_/ (___ ___)--------| P2 | 423 ( Network ) ---- +----+ 424 (__ __) 425 ---- 427 The rule set on the multi-homed node depends on the type of 428 communication established with the peers. In this example the multi- 429 homed node has established HTTP, interactive SSH and peer-to-peer 430 voice over IP traffic with its peers (P1 and P2). The PIDs PID1 and 431 PID2 maps to I1 and I2, respectively: 433 tcp peer port 80 on PID1 434 tcp peer port 22 on PID2 435 udp local port 49724 peer P2 port 56512 on PID2 437 The above rule set is distributed to the peer nodes. How the rule 438 set is transferred to the peering nodes is outside the scope of this 439 document. Whether the whole rule set or a subset of the rule set is 440 sent to the peering nodes depends on the transport protocol in use 441 and if there is any need for the peer node to have this type of 442 knowledge for its communication with the multi-homed node. If, in 443 the above example, the MA node would have established a HTTP session 444 with P1 and a HTTP and VoIP session with P2, then P1 would not need 445 any routing rules to send the return traffic back to the MA. 446 However, P2 would need to know which communication path to use for 447 the different traffic flows. 449 The implementation of the actual routing mechanism to match the rule 450 selectors and follow the rules is platform dependent. 452 3.2. How to generate a PID 454 How the Connection Manager generates the PID is outside the scope of 455 this document. For example, one possible way of doing it would be 456 for the Connection Manager to assign a unique PID number for all 457 traffic requesting the same (or similar) type of service (e.g., 458 bandwidth, bit error rate, latency, etc.). If the access conditions 459 changes, i.e., the Connection Manager receives new input data, new 460 bindings would be generated which could change the physical interface 461 that an existing PID number is associated with. 463 The PID is created by the multi-homed node and its uniqueness is 464 guaranteed by associating it with the multi-homed node's identity 465 tag. 467 3.3. Storing Routing Rules 469 How the routing rules are stored, in the mult-home node and in the 470 intermediate node and the peers, is implementation dependent. They 471 could be stored in a file system in the ASCII form that is described 472 in this document, but they could also be stored in, e.g., in-core 473 (binary) data structures. 475 4. Multi-Access Rule Language Overview 477 This section defines the syntax used to describe routing rules. It 478 uses the formal syntax Augmented Backus-Naur Form (ABNF) as specified 479 in [RFC5234]. 481 4.1. Rule Language Definition 483 rule-collection = RULE-SET / 1*(CONDITIONAL-SET) 484 conditional-set = CONDITION RULE-SET 485 condition = "<" NUMLIST ">" 487 rule-set = *(RULE ';') 488 rule = [ AF ] FLOW EXTRA ACTION [ WHERE ] 490 af = "ip4" | "ip6" 491 flow = ("tcp" / "udp") (PORT-ADDR-PAIR / ANY-PORT) 492 flow =/ ("ipsec" / "ah" / "esp") SPI-ADDR-PAIR 493 flow =/ "icmp" [ ICMP-SPEC ] ADDR-PAIR 494 flow =/ "proto" NEG-RANGE ADDR-PAIR 495 flow =/ "any" LABEL-ADDR-PAIR 496 extra = [ "hoplimit" NEG-RANGE ] [ "tclass" NEG-RANGE ] 497 [ "ip6h" NEG-RANGE ] 498 extra =/ [ "tos" NEG-RANGE ] [ "ttl" TTL ] 499 action = "on" (RR-LIST / CAST-LIST) / "drop" 500 where = "at" ("local" / PREFIX) 502 port-addr-pair = [ "local" PORT-ADDR ] [ "peer" PORT-ADDR ] 503 port-addr = [ PREFIX ] PORT-SPEC / PREFIX 504 any-port = PORT-SPEC ADDR-PAIR 505 spi-addr-pair = [ "local" SPI-ADDR ] [ "peer" SPI-ADDR ] 506 spi-addr = [ PREFIX ] "spi" NEG-RANGE / PREFIX 507 label-addr-pair = [ "local" LABEL-ADDR ] [ "peer" LABEL-ADDR ] 508 label-addr = [ PREFIX ] "label" NEG-RANGE / PREFIX 509 addr-pair = [ "local" PREFIX ] [ "peer" PREFIX ] 510 icmp-spec = "type" NEG-RANGE [ "code" NEG-RANGE ] 511 rr-list = NUMLIST 512 cast-list = NUMBER 1*("&" NUMBER) 514 prefix = ADDR [ "/" NUMBER ] 515 addr = HEXSEQ [ "::" [ HEXSEQ ] ] / "::" [ HEXSEQ ] 516 addr =/ 1*3DIGIT 3("." 1*3DIGIT) 517 hexseq = HEX4 *(":" HEX4) 518 hex4 = 1*4HEXDIGIT 519 port-spec = "port" NEG-RANGE 520 neg-range = [ NOT ] RANGE 521 not = "!" / "not" / "no" 522 range = NUMBER [ "-" NUMBER ] 523 numlist = NUMBER *("," NUMBER) 524 number = DEC-NUMBER / HEX-NUMBER 525 dec-number = 1*DIGIT 526 hex-number = "0x" 1*HEXDIGIT 527 hexdigit = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 528 digit = %x30-39 530 4.2. Lexical Analysis 532 The routing rules are free text in ASCII text format. White space is 533 used for token separation. Allowed white space is Space (ASCII 32), 534 Horizontal Tab (ASCII 9), and CRLF (ASCII 13 10). 536 Comments are allowed at any place where white space is allowed, and 537 will be parsed as white space. A comment starts with two slashes 538 ('/', ASCII 47), and continues to the next CRLF. 540 The routing rule language is not line based, but there is a 1024 541 octet limitation on the length of lines (including the final CRLF), 542 to simplify implementations in memory constrained devices. 544 4.3. Rule Language Semantic 546 The rule language definition presented in section 4.1 may lead to 547 semantic errors though the rule set is syntactically correct: for 548 example, the language definition allows to mix IPv6 addresses with 549 the Type of Service (tos) field in the rule selector, though the IPv6 550 header does not have such field. 552 Such design highly simplifies the language definition, but mandates 553 sanity checks when implementing a language parser. 555 5. Rule Set Semantics 557 This section explains how the syntax should be interpreted and the 558 motivation for using this specific syntax. 560 5.1. Target Node 562 The node for which the routing rules are used is called the target 563 node. The Identity Tag of the target node is given out-of-band, when 564 the rules are transmitted or installed. Exactly how this is done 565 depends on mobility mechanism used, and is outside the scope of this 566 document. 568 It is also possible to use the rules for a whole moving network, see 569 below. 571 5.2. Rules and Path Identifier 573 The routing rules will identify packet flows, and result in flows 574 being dropped or mapped to a particular Path Identifier, PID. How 575 the PID is then mapped to an actual packet transmission channel 576 depends on the mobility management method used, and is outside the 577 scope of this document. 579 When a packet is routed, the rules are checked sequentially. The 580 first rule that matches the packet is selected. What happens if no 581 rule matches, depends on the mobility mechanism, and is not defined 582 here. If the mobility mechanism supports it, it is suggested that 583 the packet will use a default path, otherwise the packet will 584 probably have to be dropped. It is strongly advised that all rule 585 sets have a catch-all default rule, and does not depend on the 586 behavior for non-matching packets. 588 5.3. Conditional Rule-Sets 590 For some scenarios, it is useful to install or transmit a collection 591 of rule-sets at the same time, and select which one to use depending 592 on what PIDs are available. How the set of available PIDs is 593 determined is outside the scope of this document. 595 When multiple rule-sets are put in a rule-collection, each rule set 596 is conditioned with a list of PIDs that should be available inside 597 angle brackets, '<' and '>'. An example: 599 <11,800> 600 tcp local port 80 on 800 601 any on 11 602 <11> 603 tcp local port 80 drop 604 any on 11 606 In the rule collection above, the first rule set will be used when 607 both PIDs 11 and 800 are available. The second rule set will be used 608 when only PID 11 is available. If no condition matches, an empty 609 rule set will be used, which implies that all packets are dropped. 611 5.4. Local and Peer Node 613 It is an explicit design goal of the language that the very same 614 rules can be used at all nodes that route traffic to or from the 615 target node. This implies that the flow description does not express 616 header source or destination, because they will have to be switched 617 depending on the direction of the packet transmission. To achieve 618 direction independence, the keyword 'local' and 'peer' are used to 619 refer to the endpoints of the flows. The target node is referred to 620 as 'local', and whatever node the target node is communicating with 621 is referred to as 'peer'. An example: 623 tcp peer port 80 on 11 625 This rule will send packets from the target node with destination 626 port 80 on PID 11, and correspondingly send packets to the target 627 node with source port 80 on the same PID. In practice, this means 628 that any TCP traffic on the standard HTTP port to or from web servers 629 will be put on PID 11. 631 5.5. Any-port 633 When using well-known ports, the port number can be used to identify 634 the type of traffic. The port number is normally checked at one of 635 the endpoints, 'local' or 'peer'. In some cases, it doesn't matter 636 which endpoint that uses the well-known port, the fact that either 637 one does is enough to classify the traffic. Traffic using a well- 638 known port could be handled by two rules together: 640 tcp local port 25 peer 2001:db8::1 on 44 641 tcp peer 2001:db8::1 port 25 on 44 643 The first rule would handle SMTP connections from any port on 2001: 644 db8::1 to the Mail Transfer Agent, MTA, at the target node. The 645 second rule would correspondingly handle SMTP connections from any 646 port on the target node to the MTA at 2001:db8::1. Note that the 647 rules can not be collapsed like this: 649 tcp local port 25 peer 2001:db8::1 port 25 on 44 651 This would only match flows using port number 25 at both ends, which 652 is normally not the case. 654 To avoid the double rules in the common case of traffic 655 classification on (well-known) port numbers, the any-port mechanism 656 can be used. When used, it means that at least one of the local and 657 peer port number must match. An example: 659 tcp port 25 peer 2001:db8::1 on 44 661 This rule would handle any SMTP traffic between the target node and 662 2001:db8::1, and has the same meaning as the two rules above have 663 together. Note that the port number is given before any 'local' or 664 'peer' clauses. 666 5.6. Ranges 668 At many places where a number is given, a NEG-RANGE can be used. It 669 is a numerical range, which can be optionally negated. Some examples 670 where ranges are used for port numbers: 672 tcp port 49152-65535 on 13 673 tcp port not 137-139 on 14 675 5.7. IPsec 677 IPsec traffic can be recognized as one of the IP protocols AH and 678 ESP. The keyword 'ipsec' is a shortcut for any of AH and ESP. When 679 matching IPsec traffic, the SPI can be used for more specific 680 matching: 682 esp local spi 1500-1599 on 11 683 esp peer 2001:db8::1 spi 444 on 11 684 ipsec on 44 686 5.8. ICMP 688 ICMP packets can be matched on type and code. 690 5.9. Explicit IP Protocol Numbers 692 It is possible to match flows on protocol numbers: 694 proto 138-255 drop 696 This will drop any packets with IP protocol number between 138 and 697 255. 699 5.10. Any IP Protocol and Flow Labels 701 If the IP protocol number should not be checked, the 'any' keyword 702 can be used. An 'any' rule allows matching on the IPv6 header flow 703 label: 705 any peer 2001:db8::1 flow 99 on 15 706 any local flow 42 on 15 707 any on 17 709 5.11. Extra clauses 711 It is possible to match each packet on a few other things: 713 o The IPv6 header hop limit 715 o The IPv6 header traffic class 717 o Whether some particular extension headers are included 719 o The IPv4 Type of Service field 721 One or more of these checks can be included in each rule. 723 5.12. Asymmetric Routing 725 Asymmetric routing means that the packets of a particular flow is not 726 using the same path in both directions. This can be useful when 727 using networks that are intrinsically asymmetric, like satellite 728 networks. 730 One way to achieve asymmetric routing is to have different rules at 731 the target node and at the routing proxy or peers. In some 732 scenarios, it is valuable to have the very same rules at all places 733 even in the case of asymmetric routing. To support this, each rule 734 can have an "at" clause. The "at" clause means that the rule is only 735 applicable at that address or prefix. As a special case, the keyword 736 'local' is used to refer to the target node. An example: 738 udp peer 2001:db8::15 on 11 at local 739 udp peer 2001:db8::15 on 22 741 The first rule will only be applied at the target node, so PID 11 742 will be used for UDP traffic from the target node to 2001:db8::15. 743 All other nodes (routing proxy or peer nodes) will apply the second 744 rule, and UDP traffic from 2001:db8::15 to the target node will use 745 PID 22. 747 5.13. Round-robin 749 For load-sharing purposes, round-robin transmission is supported. To 750 use round-robin, a list of PIDs is given instead of just one: 752 udp peer 2001:db8:1c32::/48 port 44100 on 4, 4, 5 754 Here, UDP traffic from port 44100 at any node in prefix 2001:db8: 755 1c32::/48 will be sent on PIDs 4 and 5. Two out of three packets 756 will go on PID 4, which presumably has twice the bandwidth of PID 5. 758 5.14. n-casting 760 In some specific cases, like important signaling, it can be useful to 761 send the packets on multiple PIDs in parallel. All type of traffic 762 is not suited for n-casting. For instance, TCP is known to be 763 sensitive for re-ordering of packets and n-casting may cause TCP slow 764 start. However, the routing rules provides a mechanism to handle 765 transport protocols differently, which would make it possible to use 766 n-casting for, e.g., some UDP traffic: 768 udp peer port 5060 on 11 & 800 770 This would transfer UDP packets to and from peer port 5060 on both 771 PID 11 and PID 800. 773 5.15. Mobile Networks 775 A set of rules can be used for an entire moving network. By default, 776 'local' will then refer to all the nodes of the mobile network. When 777 a particular MNN (or set of MNNs) needs special routing, an address 778 or prefix can be used after 'local'. An example: 780 udp local 2001:db8::19 port 5600 on 18 781 udp local port 5600 on 19 783 The first rule will give special treatment to the MNN 2001:db8::19, 784 all other MNNs will be handled by the second rule. 786 6. Generating Routing Rules and Bindings 788 This section describes when and how routing rules and bindings are 789 generated and sent from the local node to the intermediate and 790 peering nodes. 792 6.1. Generating Routing Rules 794 Routing rules could be generated either by the multi-homed node 795 itself or by a trusted network node on behalf of the multi-homed 796 node. The multi-homed node is an obvious candidate for generating 797 routing rules and bindings since it's aware of all the information 798 needed by the Connection Manager. It would also be able to react 799 instantly whenever an event occurs that requires an immediate action. 800 However, there may be situations when a trusted network node could 801 generate some or all routing rules and bindings. If everything is 802 generated by this node additional communication between the multi- 803 homed node and this trusted network node would be required. The 804 actual implementation of this is outside the scope of this document. 806 The frequency at which the routing rules are generated is an 807 implementation issue. Depending on the target node type, the 808 Connection Manager may generate the whole set of routing rules as the 809 node is initiated or it could prefer to have a more dynamic approach 810 and generate the routing rules on demand as the node initiate 811 applications. 813 In case of a static approach the required routing rules exists once 814 the multi-homed node has been initiated and it's assumed that they 815 will change with a low frequency. 817 In case of a dynamic approach there are several events that may 818 trigger the creation of a new routing rule. For example when an 819 application requests to open a socket the Connection Manager 820 application would create a new routing rule with an associated PID 821 number. As the user starts different applications, the rule set will 822 expand and there will be multiple routing rules, each of one 823 targeting a specific data flow, with information of how the multi- 824 homed node prefer inbound and outbound traffic to be routed. The 825 rule set is dynamic in the sense that if an application is terminated 826 then associated routing rules are removed. 828 6.2. Generating Bindings 830 The Binding is a mapping between the PID and a physical IP address. 831 How this mapping is done depends on the mobility mechanism in use and 832 is outside the scope of this document. The syntax defines a selector 833 which is associated with a PID. 835 There are several events that may trigger the creation of a new 836 binding. For example when an interface becomes available or is 837 deactivated, or when the signal strength goes below a certain 838 threshold value, etc. All these events are input to the Connection 839 Manager that evaluates it, based on certain criteria that have been 840 defined by the user and/or operator, and generates a new set of 841 bindings that reflects the current status of the multi-homed node's 842 communication capacity. 844 6.3. Sending Routing Rules and Bindings to Peering Nodes 846 When a new routing rule or a binding has been created, this 847 information must be sent to the intermediate and peering nodes to 848 make sure that these nodes knows which destination address to use if 849 there exist multiple addresses associated with the multi-homed node's 850 identity tag. 852 Whether the entire rule set or a subset of it is sent to a peering 853 node depends on the transport protocol in use and is outside the 854 scope of this document. 856 7. Security Considerations 858 This document specifies a language and not a protocol. Hence, there 859 are no inherent security issues related to this specification. 861 However, when the routing rules and bindings are distributed and 862 installed, authentication and authorization must be ensured. Exactly 863 how this is done is outside the scope of this document. 864 Additionally, the address scope of the routing rules (in particular 865 rules using "local " clauses) must be checked, to not include 866 addresses outside the allowed range. Failure to do these checks can 867 make it possible to do unauthorized routing changes for network 868 traffic to other hosts. 870 8. IANA Considerations 872 This memo includes no request to IANA. 874 9. Acknowledgements 876 We would like to thank (in alphabetic order) Tero Kauppinen, Henrik 877 Levkowetz, Heikki Mahkonen, and Ryuji Wakikawa for their comments and 878 suggestions on this work. 880 10. References 882 10.1. Normative References 884 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 885 Specifications: ABNF", STD 68, RFC 5234, January 2008. 887 10.2. Informative References 889 [I-D.draft-eriksson-mext-mipv6-routing-rules] 890 Eriksson, M., "Mobile IPv6 Flow Routing over Multiple 891 Care-of Addresses", 892 Internet-Document draft-eriksson-mext-mipv6-routing-rules, 893 June 2008. 895 [I-D.ietf-mext-flow-binding] 896 Soliman, H., Montavont, N., Fikouras, N., and K. 897 Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo Basic 898 Support", draft-ietf-mext-flow-binding-01 (work in 899 progress), February 2009. 901 [I-D.ietf-monami6-multiplecoa] 902 Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, 903 "Multiple Care-of Addresses Registration", 904 draft-ietf-monami6-multiplecoa-11 (work in progress), 905 January 2009. 907 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 908 August 2002. 910 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 911 in IPv6", RFC 3775, June 2004. 913 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 914 (MOBIKE)", RFC 4555, June 2006. 916 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 917 "Host Identity Protocol", RFC 5201, April 2008. 919 Appendix A. Applying the Rule Set to Mobile IPv6 921 This appendix draws examples on how to use routing rules with Mobile 922 IPv6 [RFC3775]. Other mobility management protocols would need to 923 write separate documents to outline how the routing rules are used 924 with that specific mobility management protocol. 926 The multiple care-of registration protocol 927 [I-D.ietf-monami6-multiplecoa] defines a way to maintain multiple 928 paths between two nodes. However, both communicating nodes must have 929 routing rules to know how to distribute traffic flows between the 930 different paths. There may be different ways of distributing the 931 routing rules. In case of Mobile IPv6 this could be done as defined 932 in either [I-D.ietf-mext-flow-binding] or 933 [I-D.draft-eriksson-mext-mipv6-routing-rules]. 935 A.1. Mapping Between PID and IP Address 937 In the conceptual model, the output from the Connection Manager is 938 Bindings. The binding is the actual mapping between the PID and the 939 physical IP address. By using a PID in the routing rules, a dynamic 940 binding between the PID in the routing rule and the actual physical 941 interface is achieved. In case of Mobile IPv6 the physical IP 942 address is a MIP care-of address. 944 The base Mobile IPv6 [RFC3775] specification only supports that one 945 Care-of Address (CoA) is bound to the Home Address (HoA). To achieve 946 simultaneous multi-access, the base protocol needs extensions and 947 document [I-D.ietf-monami6-multiplecoa] defines how to register 948 multiple care-of addresses bound to a single Home Address. For doing 949 so, a new Binding Unique Identification Number (BID) is carried in 950 each binding for the receiver to distinguish between the bindings 951 corresponding to the same Home Address. 953 The Connection Manager creates routing rules with the associated PID 954 and the binding between the PID, BID and care-of address as 955 illustrated below. 957 Routing Rule: PID -----> BID -----> CoA 959 In case of Mobile IPv6 the PID would typically be the BID, i.e., 960 there is no need for an explicit additional mapping. 962 A.2. Mobile IPv6 Example 964 This example is an extension of the example given in Chapter 4 and 965 shows how it can be applied to Mobile IPv6. The Mobile Node (MN) 966 with two communication paths, one over interface I1 (identified by 967 PID1) and another one over interface I2 (identified by PID2), 968 connected to two different foreign access networks. The MN is 969 communicating with two Correspondent Nodes, CN1 and CN2, either 970 directly if Route Optimization is used or via the Home Agent (HA) if 971 reverse tunneling is used. The IPv6 address assigned to CN2 is 2001: 972 db8:1411::24. Both CN1 and CN2 are single-homed. 974 +----+ 975 | HA | 976 +----+ 977 __----__ | 978 ( Access ) | 979 ( Network ) ___----___ +-----+ 980 +-------+ _ /(__ __) \ ( )--------| CN1 | 981 | I1|_/ ---- \_( ) +-----+ 982 | MN | _( Internet ) 983 | I2|_ __----__ / ( ) +-----+ 984 +-------+ \__ ( Access )_/ (___ ___)--------| CN2 | 985 ( Network ) ---- +-----+ 986 (__ __) 987 ---- 989 In this example the Connection Manager receives different input 990 events, some of them causing new routing rules and bindings to be 991 created. We assume the following scenario: 993 o The MN connects interface I1 to a Wide Area Network (WAN) and 994 interface I2 to a Wireless LAN (WLAN) network. From the MN point 995 of view both access networks are foreign networks. 997 o As the MN connects to the access network this will trigger the 998 Connection Manager to generate a binding. For interface I1, BID1 999 is assigned number 800, and for interface I2, BID2 is assigned 1000 number 11. In addition, BID1 is mapped to CoA1, which has been 1001 assigned to interface I1 and BID2 is mapped to CoA2, which has 1002 been assigned to interface I2. How this mapping is achieved is 1003 outside the scope of this specification. 1005 o According to [I-D.ietf-monami6-multiplecoa] the newly created 1006 bindings are sent to the HA where a Binding Cache entry for the 1007 MN's HoA and CoA1 and CoA2 is created. 1009 o Now the user at the MN decides to establish a HTTP session towards 1010 CN1 and at the same time call a friend that can be reached at CN2. 1011 These events (applications open sockets) are input to the 1012 Connection Manager and as a result a set of routing rules are 1013 created that reflects the current view of the MN on how these 1014 traffic flows should be routed. In this example the Connection 1015 Manager has decided to put HTTP traffic on interface I2 and the 1016 voice traffic on interface I1. 1018 tcp peer port 80 on 11 1019 udp local port 49724 peer 2001:db8:1411::24 port 56512 on 800 1021 o These routing rules will ensure that outgoing traffic from the MN 1022 is sent to the correct interface, but to also ensure that incoming 1023 traffic towards the MN is routed through the correct interface the 1024 HA also needs access to the MN's routing rules. Hence, the MN 1025 will send the newly created routing rules to the HA. In case of 1026 Mobile IPv6 this could be done as defined in either 1027 [I-D.ietf-mext-flow-binding] or 1028 [I-D.draft-eriksson-mext-mipv6-routing-rules]. 1030 o Whether the above routing rules also must be sent to the 1031 correspondent nodes depends on if the MN will do route 1032 optimization towards the CN and if the MN decides to register 1033 multiple CoAs with its HoA. If this is the case, then the CN will 1034 also need the routing information to able to make the correct 1035 choice of CoA for the traffic sent towards the MN. 1037 The routing rules in this example would be interpreted differently by 1038 the MN and the HA/CN. In case of the MN it would "send HTTP traffic 1039 with destination port 80 using CoA2 as source address" and "send 1040 voice over IP traffic with source port 49724 and destination port 1041 56512 to node 2001:db8:1411::24 using CoA1 as source address". The 1042 HA and the correspondent node(s) would "send HTTP traffic with source 1043 port 80 using CoA2 as destination address" and "send voice over IP 1044 traffic with source port 56512 and destination port 49724 using CoA1 1045 as destination address". 1047 A.2.1. Creating new Routing Rules 1049 New routing rules are typically created when an application opens a 1050 new socket. If the mobile node user decides to launch a remote login 1051 session towards CN2 the Connection Manager creates a new routing rule 1052 and decides that this traffic flow should use interface I1. After 1053 this event the rule set at the MN will be as shown below: 1055 tcp peer port 80 on 11 1056 udp local port 49724 peer 2001:db8:1411::24 port 56512 on 800 1057 tcp peer port 22 on 800 1059 The new routing rules must be sent to the HA and optionally to CN2. 1061 If for instance the MN user, during the conversation with the CN2 1062 user, gets the possibility to look at some pictures stored at CN2's 1063 computer by using HTTP, then CN2 must be aware of the MN's routing 1064 rules to be able to perform an optimized route selection. The latter 1065 assumes that the MN and CN2 route optimize the traffic sent between 1066 them. 1068 A.2.2. Route Update 1070 If a new interface becomes available or an existing interface becomes 1071 unavailable for some reason, the Connection Manager is notified about 1072 this event and updates the routing rules and the bindings 1073 accordingly. In this example, if the WLAN (interface I2) access gets 1074 out of range the new rule set would look like below: 1076 tcp peer port 80 on 800 1077 udp local port 49724 peer 2001:db8:1411::24 port 56512 on 800 1078 tcp peer port 22 on 800 1080 Since there is only one interface available at the mobile node, a de- 1081 registration of CoA2 and removal of routing rules is needed on the HA 1082 and the correspondent nodes that has the old information stored. 1084 Appendix B. Example of Routing Rules 1086 This appendix includes a collection of routing rules giving examples 1087 of how the routing rules can be used to give a feeling for the 1088 language. 1090 Some Generic stuff: 1091 // 6BONE is dead 1092 any peer 3ffe::/16 drop 1094 // Put SSH traffic on low-latency link (uses "any-port") 1095 tcp port 22 on 12 1097 // HTTP is bulk (we don't have web server, so only match peer port) 1098 tcp peer port 80 on 13 1100 // Impress people with short ping times 1101 icmp type 128-129 on 12 1103 // Load share rtp (channel 4 is twice as fast as 5) 1104 udp peer 2001:db8:1c32::/48 port 6900 on 4, 4, 5 1106 // IPSec is asymmetric (SPIs don't match) 1107 ipsec local spi 12 on 18 1108 ipsec peer 2001:db8:8142:500::3775 spi 32 on 18 1109 ipsec on 19 1111 // Some links might be eavesdropped (23 is open, 22 is protected) 1112 esp on 23 1113 tcp port 443 on 23 1114 any on 22 1116 // Bi-cast important traffic 1117 udp peer port 5060 on 11 & 800 1119 // Route on flow label 1120 any local label 4711 on 19 1121 any peer 2001:db8::55 label 99 on 19 1123 // Use traffic class marking 1124 udp tclass 127 on 15 1125 any tclass 128-255 on 14 1127 // Use explicit protocol number 1128 proto 77 on 19 1130 // Rules not matching any address and not having an explicit address 1131 // family will match both IPv4 and IPv6 flows 1132 tcp peer port 443 on 11; 1133 udp on 12; 1135 // These two imply the same thing 1136 ip4 tcp port 80 on 12; 1137 tcp peer 0.0.0.0/0 port 80 on 12; 1139 // These are semantic errors (but syntactically OK) 1140 ip4 udp peer 2001:db8::/32 on 10; 1141 tcp local 10.12.14.16/17 peer 3ffe:1234::1 port 99 on 10; 1142 any peer 3ffe:99::1 ttl 12 on 11; 1144 // Drop any previously unmatched IPv4 traffic 1145 ip4 any drop; 1147 // Put all IPv6 traffic on a particular PID 1148 ip6 any on 10; 1150 // Extra 1151 udp local port 99 hop limit 0-22 on 44 1152 any tclass ! 127 ip6h 12-13 drop 1154 Conditional rule sets: 1155 // Depending on the active PIDs different rule sets are used 1156 <11,800> 1157 tcp local port 80 on 800 1158 any on 11 1159 <11> 1160 tcp local port 80 drop 1161 any on 11 1163 Asymmetric routing: 1164 // Send tcp on 19 on uplink, 22 on downlink 1165 tcp on 19 at local 1166 tcp on 22 1168 Mobile networks: 1169 // MNN 2001:db8::77 gets special treatment 1170 udp local 2001:db8::77 port 4400 on 19 1171 udp local port 4400 on 22 1173 Authors' Addresses 1175 Conny Larsson 1176 Ericsson Research 1177 Isafjordsgatan 14E 1178 Stockholm SE-164 80 1179 Sweden 1181 Phone: +46 8 404 8458 1182 Email: conny.larsson@ericsson.com 1184 Michael Eriksson 1185 Ericsson Research 1186 Isafjordsgatan 14E 1187 Stockholm SE-164 80 1188 Sweden 1190 Phone: +46 8 757 5888 1191 Email: michael.eriksson@ericsson.com 1193 Koshiro Mitsuya 1194 Keio University 1195 5322 Endo 1196 Fujisawa, Kanagawa 252-8520 1197 Japan 1199 Phone: +81 466 49 1100 1200 Email: mitsuya@sfc.wide.ad.jp 1201 URI: http://www.sfc.wide.ad.jp/~mitsuya/ 1203 Kazuyuki Tasaka 1204 KDDI R&D Laboratories Inc. 1205 2-1-15 Ohara 1206 Fujimino, Saitama 356-8502 1207 Japan 1209 Phone: +81 49 278 7574 1210 Email: ka-tasaka@kddilabs.jp 1211 Romain Kuntz 1212 Louis Pasteur University / LSIIT 1213 Strasbourg 1214 France 1216 Phone: +33 390 244 584 1217 Email: kuntz@lsiit.u-strasbg.fr 1218 URI: http://clarinet.u-strasbg.fr/~kuntz/