idnits 2.17.1 draft-ietf-mext-flow-binding-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. 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 (April 28, 2009) is 5478 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 (-14) exists of draft-ietf-monami6-multiplecoa-13 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF MEXT Working Group H. Soliman 3 Internet-Draft Elevate Technologies 4 Intended status: Standards Track G. Tsirtsis 5 Expires: October 30, 2009 Qualcomm 6 N. Montavont 7 IT/TB 8 G. Giaretta 9 Qualcomm 10 K. Kuladinithi 11 University of Bremen 12 April 28, 2009 14 Flow Bindings in Mobile IPv6 and Nemo Basic Support 15 draft-ietf-mext-flow-binding-02.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on October 30, 2009. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents in effect on the date of 47 publication of this document (http://trustee.ietf.org/license-info). 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. 51 Abstract 53 This document introduces extensions to Mobile IPv6 that allow nodes 54 to bind one or more flows to a care-of address. These extensions 55 allow multihomed nodes to instruct their peers to direct downlink 56 flows to specific addresses. 58 Table of Contents 60 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 8 64 4.1. Definition Update for Binding Identifier Mobility 65 Option . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.2. Flow Identification Mobility Option . . . . . . . . . . . 8 67 4.2.1. Binding Reference Sub-option . . . . . . . . . . . . . 11 68 4.2.2. Flow Description Sub-option . . . . . . . . . . . . . 12 69 4.3. Flow Identification Summary Mobility Option . . . . . . . 13 70 4.4. Flow Bindings entries list and its relationship to 71 Binding Cache . . . . . . . . . . . . . . . . . . . . . . 14 72 5. Protocol operations . . . . . . . . . . . . . . . . . . . . . 17 73 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 5.1.1. Preferred Care-of address . . . . . . . . . . . . . . 17 75 5.2. Mobile Node Considerations . . . . . . . . . . . . . . . . 17 76 5.2.1. Sending BU with BID Options . . . . . . . . . . . . . 18 77 5.2.2. Sending BU with Flow Identification Options . . . . . 18 78 5.2.3. Sending BU with a Flow Summary Option . . . . . . . . 20 79 5.2.4. Removing flow bindings . . . . . . . . . . . . . . . . 21 80 5.2.5. Receiving Binding Acknowledgements . . . . . . . . . . 21 81 5.2.6. Return Routability Procedure . . . . . . . . . . . . . 21 82 5.3. HA, MAP, and CN Considerations . . . . . . . . . . . . . . 22 83 5.3.1. Receiving BU with BID Options . . . . . . . . . . . . 22 84 5.3.2. Receiving BU with Flow Identification Options . . . . 23 85 5.3.3. Receiving BU with Flow Summary Option . . . . . . . . 25 86 5.3.4. Handling flow binding Removals . . . . . . . . . . . . 26 87 5.3.5. Sending Binding Acknowledgements . . . . . . . . . . . 26 88 5.3.6. Packet Processing . . . . . . . . . . . . . . . . . . 27 89 6. Security considerations . . . . . . . . . . . . . . . . . . . 28 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 91 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 92 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 94 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32 95 10.2. Informative References . . . . . . . . . . . . . . . . . . 32 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 98 1. Requirements notation 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 2. Introduction 106 Mobile IPv6 [RFC3775], DSMIPv6 [I-D.ietf-mext-nemo-v4traversal] and 107 Nemo Basic Support [RFC3963] allow a mobile node / mobile router to 108 manage its mobility using the binding update message, which binds one 109 care-of address to one home address. The binding update message can 110 be sent to the home agent. In Mobile IPv6, the binding update can 111 also be sent to correspondent node or to a mobility anchor point (see 112 [RFC5380]). The semantics of the binding update are limited to 113 care-of address changes. That is, [RFC3775], 114 [I-D.ietf-mext-nemo-v4traversal], and [RFC3963] do not allow a mobile 115 node / mobile router to bind more than one address to the home 116 address. In [I-D.ietf-monami6-multiplecoa] Mobile IPv6 and Nemo 117 Basic Support are extended to allow the binding of more than one 118 care-of address to a home address. This specification further 119 extends Mobile IPv6, DSMIPv6, and Nemo Basic Support to allow it to 120 specify policies associated with each binding. A policy can contain 121 a request for a special treatment of a particular IPv4 or IPv6 flow, 122 which is viewed as a group of packets matching a flow descriptor. 123 Hence, this specification allows a mobile node / mobile router to 124 bind a particular flow to a care-of address without affecting other 125 flows using the same home address. In addition, this specification 126 allows to bind a particular flow to a particular care-of address 127 directly with correspondent node and mobility anchor point. 129 In this document, a flow is defined as a set of IP packets matching a 130 flow descriptor. A flow descriptor can identify the source and 131 destination IP addresses, transport protocol number, the source and 132 destination port numbers and other fields in IP and higher layer 133 headers. This specification, however, does not define flow 134 descriptors and it is assumed that one or more ways of defining flow 135 descriptors are going to be defined in other specifications. This 136 specification, however, does define the sub-option extension format 137 to be used for any defined flows descriptors. 139 Using the flow identifier option introduced in this specification a 140 mobile node / mobile router can bind one or more flows to a care-of 141 address while maintaining the reception of other flows on another 142 care-of address. Requesting the flow binding can be decided based on 143 local policies within the mobile node / mobile router and based on 144 the link characteristics and the types of applications running at the 145 time. Such policies are outside the scope of this document. 147 It should be noted that the flow identification option can be 148 associated with any binding update, whether it is sent to a home 149 agent, correspondent node (in the case of Mobile IPv6), or mobility 150 anchor point (in the case of Hierarchical Mobile IPv6). 152 In the rest of the document, the term "mobile node" is used to 153 designate either a mobile node as defined in [RFC3775] or a mobile 154 router as defined in [RFC3963] unless stated otherwise. 156 3. Terminology 158 Terms used in this document are defined in [RFC3753] and [RFC4885]. 159 The following terms are also used in this document: 161 Flow: A flow is identified as a set of data packets that are 162 exchanged between two nodes and match a given flow description 164 Flow Description: A set of instructions that describes a flow. 166 Flow Identifier: Identifier of a flow binding. 168 Flow binding: An entry in the list of flow binding associated with 169 a given mobile node. 171 4. Mobile IPv6 Extensions 173 This section introduces extensions to Mobile IPv6 that are necessary 174 for supporting the flow binding mechanism described in this document. 176 4.1. Definition Update for Binding Identifier Mobility Option 178 This specification updates the definition of the Binding Identifier 179 Mobility option defined in [I-D.ietf-monami6-multiplecoa], as 180 follows: 182 1 2 3 183 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Type = TBD | Length | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Binding ID (BID) | Status |H| BID-PRI | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 189 + + 190 : IPv4 or IPv6 care-of address (CoA) : 191 + + 192 +---------------------------------------------------------------+ 194 Figure 1: The Binding Identifier Mobility option 196 BID-PRI 198 This is a 7-bit field placing each BID to a relative priority 199 with other registered BIDs. Value "0" is reserved for 200 implementation of [I-D.ietf-monami6-multiplecoa] that do not 201 support this specification. A higher number in this field 202 indicates lower priority, while BIDs with the same BID-PRI 203 value have equal priority. 205 4.2. Flow Identification Mobility Option 207 The Flow identification mobility option is included in the binding 208 update and acknowledgement messages. This option contains 209 information that allows the receiver of a binding update to install 210 policies on a traffic flow and route it to a given care-of address. 211 Multiple options may exist within the same binding update message. 213 0 1 2 3 214 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Option Type | Option Len | FID | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | FID-PRI | Action | Rsvd | PRO | Status | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Figure 2: The flow identification mobility option 223 Option Type 225 TBD 227 Option Len 229 Length of option, including any sub-options, in 8-octet units 231 FID 233 The Flow Identifier field is an 8-bit unsigned integer that 234 includes the identifier for the flow binding. This field is 235 used to refer to an existing binding or to create a new 236 binding. The value of this field is set by the mobile node. 238 FID-PRI 240 This is an 8-bit priority field to indicate the priority of a 241 particular option. This field is needed in cases where two 242 different flow descriptions in two different options overlap. 243 The priority field decides which policy should be in those 244 cases. A lower number in this field indicates a higher 245 priority. 247 Action 249 This field specifies the action that needs to be taken by the 250 receiver of the binding update containing the flow 251 identification option. The details of these requests are 252 discussed below. 254 Rsvd 256 This field is unused. It MUST be initialized to zero by the 257 sender and MUST be ignored by the receiver. 259 PRO 261 This is a 4-bit field that describes the required processing 262 for the option. This field may indicate a request for adding, 263 deleting, modifying or refreshing the option. The details of 264 these requests are discussed below. 266 Status 268 This field indicates the success or failure of the flow binding 269 operation for the particular flow in the option. This field is 270 not relevant to the binding update message as a whole or to 271 other flow identification options. Values from 0 to 127 272 indicate success. Values of 128 and higher indicate failure. 273 This field is only relevant when included in the Binding 274 Acknowledgement message and must be ignored in the binding 275 update message. 277 The following values are reserved for the PRO field in this option: 279 0 Add a flow binding 281 1 Modify a flow binding 283 The following values are reserved for the Action field in this 284 option: 286 1 Forward. This value indicates a request to forward a flow to 287 the address indicated in the Binding Reference sub-option. A 288 single BID MUST be associated with this Action. 290 2 Discard. This value indicates a request to discard all packets 291 in the flow described by the option. No BIDs are associated with 292 this Action. 294 3 n-cast. This value indicates a request to replicate the flow to 295 several addresses indicated in the Binding Reference sub-option. 296 One or more BIDs MUST be associated with this Action. 298 The following values are reserved for the status field within the 299 flow identification option: 301 0 Flow binding successful. 303 128 Flow binding rejected, reason unspecified. 305 129 Flow identification option poorly formed. 307 130 Administratively prohibited. 309 135 FID already in use 311 136 FID not found 313 137 FD-Type not supported. 315 138 Discard function not supported. 317 139 N-cast function not supported. 319 It should be noted that per-packet load balancing may have negative 320 impacts on TCP congestion avoidance mechanisms as it is desirable to 321 maintain order between packets belonging to the same TCP connection. 322 This behaviour is specified in RFC2702 [RFC2702]. Other negative 323 impacts are also foreseen for other types of real time connections 324 due to the potential variations in RTT between packets. Hence per- 325 packet load balancing is not currently supported in this extension. 327 A number of sub-options can follow the option defined in this 328 section. These are defined below. 330 4.2.1. Binding Reference Sub-option 332 This section introduces the Binding Reference sub-option, which may 333 be included in the Flow identification option. The Binding Reference 334 sub-option includes one or more BIDs defined in MCoA 335 [I-D.ietf-monami6-multiplecoa]. When this sub-option is included in 336 the Flow identification option it associates the flow described with 337 one or more registered BIDs. 339 The binding identifier option, defined in 340 [I-D.ietf-monami6-multiplecoa], registering a given BID which is then 341 indicated in the Binding Reference sub-option, MUST be either defined 342 in the same or earlier BU from the one including the binding 343 reference sub-option. The Binding Reference sub-option is shown 344 below. 346 0 1 2 3 347 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 |Sub-opt Type | Sub-Opt Len | BID | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | BID ........ 352 +-+-+-+-+-+-+-+-+-+- 354 Figure 3: The Binding Reference sub-option 356 Sub-opt Type 358 Indicates the Sub-option type. For the Binding Reference sub- 359 option, this field MUST be set to 1. 361 Sub-opt Len 363 Indicates the sub-option length in octets. This field includes 364 the entire length of the sub-option including the Sub-opt Type 365 and Sub-opt-Len fields. 367 BID 369 The BID that the mobile node wants to associate with the flow 370 identification option. One or more BID fields can be included 371 in this sub-option. Since each BID is 2 byte long, the value 372 of the Sub-opt Len field indicates the number of BIDs present. 373 Number of BIDs = (Sub-opt Len-2)/2. 375 4.2.2. Flow Description Sub-option 377 The Flow description sub-option(s) include the parameters used to 378 match packets for a specific flow binding. 380 0 1 2 3 381 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 |Sub-opt Type | Sub-Opt Len | Flow Description ... 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 Figure 4: The Flow Description sub-option 388 Sub-opt Type 390 Indicates the Sub-option type. For the flow description sub- 391 option, this field SHOULD be set to one of the FD types defined 392 below. 394 Sub-opt Len 396 Indicates the sub-option length in octets. This field includes 397 the entire length of the sub-option including the Sub-opt Type 398 and Sub-opt-Len fields. 400 Flow Description 402 The flow description corresponding to the type indicated by the 403 Sub-opt Type field. Flow description is out of scope of this 404 document. 406 The following values are reserved for the sub-option Type values are 407 defined for Flow Description: 409 17-32 reserved for Flow Description formats. 411 4.3. Flow Identification Summary Mobility Option 413 TBD 415 0 1 2 3 416 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Option Type | Option Len | FID | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | FID ........ 421 +-+-+-+-+-+-+-+-+-+- 423 Figure 5: The Flow Identification Summary Option 425 Option Type 427 Indicates the Sub-option type. For the Binding Reference sub- 428 option, this field MUST be set to 1. 430 Option Length 432 Indicates the sub-option length in octets. This field includes 433 the entire length of the sub-option including the Sub-opt Type 434 and Sub-opt-Len fields. 436 FID 438 A registered FID. One or more FID fields can be included in 439 this option. Since each FID is 2 bytes long, the value of the 440 Option Len field indicates the number of FIDs present. Number 441 of FIDs = (Sub-opt Len-2)/2. 443 4.4. Flow Bindings entries list and its relationship to Binding Cache 445 The conceptual mobile IPv6 binding cache was defined in [RFC3775] to 446 identify the mobile IP state maintained by the mobile node, home 447 agent, and corresponding node. The binding cache includes, between 448 others, the mobile node's home address, the registered care-of 449 address, and the lifetime of the binding. The binding cache was then 450 extended by [I-D.ietf-monami6-multiplecoa] to include more than one 451 care-of addresses and to associate each of them with a Binding 452 Identifier (BID). 454 This specification does not change modify the mobile IPv6 binding 455 cache any further. 457 Flow bindings can be thought of as a conceptual list of entries that 458 is separate from the binding cache. The flow bindings list contains 459 an entry for each of the registered flow binding. Flow binding 460 entries can point to an entry in the binding cache by means of the 461 BID. Each flow binding entry include the following parameters : 463 * FID (Flow Identifier): For a given mobile node, identified by 464 its primary home address, the FID MUST uniquely identify an 465 entry, i.e. a unique flow binding. Each mobile node can only 466 have a single entry identified by a given FID at any one time. 467 Different mobile nodes can use the same FID number space. 469 * A Flow Descriptor: Included in a Flow Description sub-option. 471 * BID(s): The list of BIDs associated with the entry as defined 472 by the Binding Reference sub-option included in the FID option 473 that created it. 475 * Action: The action associated with a given entry as defined by 476 the PRO field of the FID option that created it 478 * Active/Inactive flag: This flag indicates whether the entry is 479 active or inactive. 481 The flow bindings list is associated with a given mobile node, and 482 the corresponding binding cache. An entry in the flow bindings list, 483 however, is identified by the FID and the list is ordered according 484 to the FID-PRI field as defined in the FID option that created each 485 entry. 487 The BIDs included in a given entry point to a corresponding entry in 488 the binding cache for the purpose of identifying a care-of address. 490 Depending on the Action parameter in a given entry a valid BID is 491 required to make the entry "active". If all of the BIDs pointed to 492 by a given entry are not valid BIDs in the binding cache, the flow 493 binding entry becomes "inactive", in other words it does not affect 494 data traffic. Note that if the action parameter in an entry 495 indicates "n-cast" then the entry becomes inactive only if none of 496 the BIDs is valid. If only some of the BIDs are valid, the invalid 497 BIDs are simply ignored. 499 Also note that the state described in this section is maintained by 500 the mobile node as well as in mobility agents and corresponding 501 nodes. As such the mobile node is fully aware of which are the valid 502 BIDs at any time and which flow binding entries are active/inactive. 503 Section 5 defines how these flow binding entries are manipulated by 504 the mobile node in detail. 506 As an example the following represents an ordered flow bindings 507 entries table for a mobile node that has registered three care-of 508 addresses and three flow bindings. 510 FID-PRI FID Flow Description BIDs Action A/I 511 ------- --- ---------------- ---- ------- ------ 512 10 4 TCP 2 Forward Active 513 20 3 srcAddr=IPx N/A Discard Active 514 30 2 srcAddr=IPy 4 Forward Inactive 515 40 5 UDP 1,3 N-Cast Active 517 Ordered Flow Binding Entries 519 According to the above list of flow binding entries, all TCP traffic 520 will match the first entry, and according to the Action indicated it 521 will be forwarded to BID2, corresponding to a given care-of address 522 (IP3), as shown below. Any traffic that is not TCP, but has as 523 source address IPx will match the second entry, and according to the 524 associated Action it will be discarded. Note that any TCP traffic 525 with source address IPx will match the first entry and thus it will 526 be forwarded as per that entry. 528 The third entry is marked as Inactive since the BID 4 does not exist 529 in the ordered list of BID entries below. Inactive entries do not 530 affect traffic, i.e., packets are not matched against them. 532 Any UDP traffic that does not match any of the earlier entries will 533 match the third rule and according to the Action indicated it will be 534 replicated and forwarded to BIDs 1 and 3, corresponding to care-of 535 addresses IP1 and IP2 shown below. 537 Finally any remaining packets that do not match any of the entries 538 above will be simply forwarded to the care-of address indicated by 539 the highest order BID in the table below. In the example, such 540 packets will be forwarded to BID 1, corresponding to care-of address 541 IP1. 543 BID-PRI BID CoA 544 --------- --- --- 545 20 1 IP1 546 30 3 IP2 547 30 2 IP3 549 Ordered BID Entries 551 5. Protocol operations 553 5.1. General 555 This specification introduces a flow bindings list of entries and an 556 ordered list of binding identifiers, allowing mobile nodes to 557 associate flow binding policies with the registered care-of 558 addresses. 560 The flow identification option defines how the mobile node can 561 control a set of flow binding entries maintained in a home agent, 562 correspondent node, or mobility anchor points, on its behalf. The 563 fields of the flow identification option are necessary for ordering 564 flow identification options, indicating the sort of action that 565 should be undertaken to the recipient's flow binding list of entries 566 or for carrying the results of such a petition. 568 This specification allows mobile nodes to direct flows to a 569 particular care-of address. The granularity of what constitutes a 570 flow depends on the flow descriptor used. As indicated earlier the 571 flow description itself is defined in another document. 573 The remaining of this section discusses how mobile nodes can use the 574 options and sub-options defined in this document when sending binding 575 updates to the correspondent node, home agent or mobility anchor 576 point. In addition, refresh, deletion, and modification of bindings 577 are all discussed below. 579 5.1.1. Preferred Care-of address 581 Any node that supports this specification MUST maintain an ordered 582 list of care-of addresses for each mobile node it maintains a list of 583 flow bindings for. The ordered list of care-of addresses is built 584 based on the BID-PRI field of the Binding Identifier option (see 585 Section 4.1). 587 The ordered list of BIDs is used to determine how to forward a packet 588 to a given mobile node when the packet does not match any of the flow 589 binding entries defined in Section 4.4. A packet that does not match 590 any of the flow binding entries SHOULD be forwarded to the care-of 591 address identified by the BID with the highest priority i.e., lowest 592 BID-PRI value. 594 5.2. Mobile Node Considerations 596 This specification allows the mobile node to maintain several 597 bindings in its home agent and to direct packets to different care-of 598 addresses according to flow bindings. This section details the 599 mobile node operations necessary to implement this specification. 601 The home agent list of flow bindings is manipulated by the mobile 602 node, via flow identification and flow summary options included in 603 binding update messages. Each flow binding update can add, modify, 604 refresh, or delete a given binding. More than one flow 605 identification options MAY be included in the same binding update but 606 each of them MUST include a different FID. In other words, two flow 607 identification options in the same message can not be about the same 608 flow binding. 610 All flow binding state MUST be refreshed in every binding update the 611 mobile node sends. Any previously registered flow binding that is 612 not included in a given binding update will be deleted. So, any flow 613 bindings that are not added or modified by a flow identification 614 option, but have previously registered and need to be maintained MUST 615 be included in a flow summary option. Only one flow summary option 616 can be included in a given binding update. 618 5.2.1. Sending BU with BID Options 620 This specification (see Section 4.1) updates the definition of the 621 Binding Identifier option, originally defined in 622 [I-D.ietf-monami6-multiplecoa]. According to this specification the 623 BID option includes a BID-PRI field assigning each registered care-of 624 address a priority, and thus placing them in an ordered list as also 625 described in Section 4.4. 627 Mobile nodes supporting this specification MUST use the BID option 628 format defined in Section 4.1. Mobiles nodes MUST also register all 629 care-of addresses using the updated BID option format, either in the 630 same BU as any flow identification options using them, or in earlier 631 BUs. 633 5.2.2. Sending BU with Flow Identification Options 635 5.2.2.1. Adding flow bindings 637 When adding a new flow binding, a mobile node sends the flow 638 identification option in the binding update. The care-of address 639 concerned with each flow identification option in the binding update, 640 must be logically registered by this binding update, or must have 641 already been registered by the receiver of the binding update in an 642 earlier binding update , as defined in Section 5.2.1. 644 The flow identification option MUST include a unique Flow Identifier 645 in the FID field. The FID needs only be unique for the receiver of 646 the binding update and for the same sender, i.e. the same FID can be 647 used across different receivers of the binding update, for the same 648 sender. 650 The FID-PRI field is set to the desired priority of the FID, 651 defining the order of the binding to be added in the list of flow 652 binding entries as defined in Section 4.4. 654 The Action field is set to one of the defined action codes (see 655 Section 4.2). 657 The PRO field MUST indicate an Add operation. 659 The Status filed is set to zero in all binding update messages. 661 The mobile node MUST include exactly one Flow Description sub-option 662 (see Section 4.2.2) describing the flow associated with the new 663 binding. 665 The mobile node MAY also include exactly one BID Reference sub-option 666 (see Section 4.2.1) to associate the flow binding with a given set of 667 BIDs and corresponding CoAs. Depending on the Action field of the 668 Flow Binding Identifier option, the following rules MUST be followed 669 with respect to the Binding Reference sub-option: 671 - if the Action indicates 'Forward', a single Binding Reference 672 sub-option with a single BID MUST be included. This BID MUST be 673 associated with a single care-of address. 675 - if the Action indicates 'Discard', the Binding Reference sub- 676 option SHOULD NOT be included. If it is included it will be 677 ignored by the receiver. 679 - if the Action indicates 'n-cast', a single Binding Reference 680 sub-option with one or more BIDs MUST be included. 682 5.2.2.2. Modifying flow bindings 684 Flow binding modification is essentially a process where an existing 685 flow binding is removed from the list of flow binding entries and a 686 new flow binding (included in the option) is added, and given the 687 same FID as the flow that was removed. With this procedure the 688 mobile node can change the action, the priority, the BID, or the flow 689 description associated with a flow binding. 691 To modify an existing flow binding the mobile node MUST send a 692 binding update with a flow identification option, with the FID field 693 set to one of the FID values already in the list of flow binding 694 entries. 696 The PRO field MUST be set to 1, indicating a request to modify the 697 binding. 699 The FID-PRI and Action fields MUST be set to the desired values to 700 be implemented with this modification. 702 The Status field is set to zero since this option is in a binding 703 update. 705 The mobile node MAY include exactly one Flow Description sub-option 706 (see Section 4.2.2) describing the modified flow to be associated 707 with the binding. 709 The mobile node MAY also include exactly one BID Reference sub-option 710 (see Section 4.2.1) to associate the existing binding with a new set 711 of CoAs. The rules regarding the Binding Reference sub-option in 712 this case are identical to those described from flow binding addition 713 in Section 5.2.2.1 . 715 Note that it is also possible for the mobile node to effectively 716 modify the effect of a flow binding entry without actually changing 717 the entry itself. This can be done by changing the CoA associated 718 with a given BID, which is a process defined in detail in 719 [I-D.ietf-monami6-multiplecoa]. 721 5.2.3. Sending BU with a Flow Summary Option 723 When the mobile node sends a binding update it MUST refresh all flow 724 bindings it wants to maintain even if it does not want to change any 725 of their parameters. 727 To refresh an existing flow binding the mobile node MUST send a 728 binding update with a flow summary option. The flow summary option 729 MUST include one or more FID fields as indicated in Section 4.3. 730 Each FID field included MUST be set to one of the FID values already 731 in the list of flow binding entries. 733 Any flow bindings (active or inactive) that are not included in a 734 binding update will be removed from the list of flow binding entries. 736 Note that any inactive flow bindings, i.e., flow bindings without 737 associated BIDs that are marked as Inactive in the list of flow 738 binding entries (see Section 4.4, MUST also be refreshed, or 739 modified, to be maintained. If they are not included in a BU they 740 will be removed. 742 5.2.4. Removing flow bindings 744 Removal of flow binging entries is performed implicitly by omission 745 of a given FID from a binding update. 747 To remove a flow binding the MN simply sends a binding update that 748 includes flow identification and flow summary options for all the 749 FIDs that need to be refreshed, modified, or added, and simply omits 750 any FIDs that need to be removed. 752 Note that a mobile node can also remove the BIDs associated with a 753 given Flow Binding, without removing the flow binding itself. The 754 procedure for removing a BID is defined in detail in 755 [I-D.ietf-monami6-multiplecoa]. 757 When all the BIDs associated with a flow binding are removed, the 758 flow binding MUST be marked as inactive in the list of flow binding 759 entries as shown in Section 4.4. In other words the state associated 760 with the flow binding MUST be maintained but it does no longer affect 761 the mobile node's traffic. The MN can return an inactive flow 762 binding to the active state by using the flow binding modification 763 process described in Section 5.2.2.2, to associate it again with one 764 or more valid BIDs. 766 5.2.5. Receiving Binding Acknowledgements 768 According to [RFC3775] all nodes are required to silently ignore 769 mobility options not understood while processing binding updates. As 770 such a mobile node receiving a Binding Acknowledgement in response to 771 the transmission of a binding update MUST determine if the Binding 772 Acknowledgement contains a copy of every flow identification options 773 included in the binding update. A Binding Acknowledgement without 774 flow identification option(s), in response to a Binding Update with 775 flow identification option, would indicate inability (or 776 unwillingness) on behalf of the source node to support the extensions 777 presented in this document. 779 If a received Binding Acknowledgement contains a copy of of each flow 780 identification option that was sent within the binding update, the 781 status field of each flow identification option indicates the status 782 of the flow binding on the distant node. 784 5.2.6. Return Routability Procedure 786 A mobile node may perform route optimization with correspondent nodes 787 as defined in [RFC3775]. Route optimization allows a mobile node to 788 bind a care-of address to a home address in order to allow the 789 correspondent node to direct the traffic to the current location of 790 the mobile node. Before sending a Binding Update to correspondent 791 node, the Return Routability Procedure needs to be performed between 792 the mobile node and the correspondent node. 794 This procedure is not affected by the extensions defined in this 795 document. However, since a binding update message is secured with 796 the key generated based on the home address and care-of address test, 797 a mobile node MUST NOT bind a flow to a care-of address whose keygen 798 token (see RFC3775 [RFC3775]) was not used to generate the key for 799 securing the Binding Update. This limitation prohibits the sender 800 from requesting the n-cast action before having registered each 801 care-of address one by one. 803 5.3. HA, MAP, and CN Considerations 805 This specification allows the home agents, mobility anchor points, 806 and corresponding nodes to maintain several bindings for a given home 807 address and to direct packets to different care-of addresses 808 according to flow bindings. This section details the home agent 809 operations necessary to implement this specification. These 810 operations are identical for MAPs and CNs unless otherwise stated. 812 Note that route optimization is only defined for mobile nodes (MIPv6 813 [RFC3775]), and not mobile routers (NEMOv6 [RFC3963]). Thus, these 814 sections only apply to correspondent nodes with respect to mobile 815 nodes and not for mobile routers. 817 5.3.1. Receiving BU with BID Options 819 This specification (see Section 4.1) updates the definition of the 820 Binding Identifier option, originally defined in 821 [I-D.ietf-monami6-multiplecoa]. According to this specification the 822 BID option includes a BID-PRI field assigning each registered care-of 823 address a priority, and thus placing them in an ordered list (see 824 Section 4.4). 826 Home agents receiving BUs including BID options and flow 827 identification options MUST logically process BID options first. 828 This is because BID Reference sub-options included in the flow 829 identification options might refer to BIDs defined in BID options 830 included in the same message. 832 The BID option is processed as defined in 833 [I-D.ietf-monami6-multiplecoa] but then the BID to care-of address 834 mapping is placed in an ordered list according to the BID-PRI field 835 of the BID option. 837 5.3.2. Receiving BU with Flow Identification Options 839 When the home agent receives a binding update which includes at least 840 one Flow Identification option, it first performs the operation 841 described in section 10.3.1 of RFC3775. 843 Home agents that do not support this specification will ignore the 844 flow identification options and all their suboption, having no effect 845 on the operation of the rest of the protocol. 847 If the binding update is accepted, and the home agent is willing to 848 support flow bindings for this MN, the home agent checks the flow 849 identification options. 851 If more than one flow identification option in the same BU, has the 852 same value in the FID field, all the flow identification options MUST 853 be rejected. 855 If all FID fields have different values the flow identification 856 options can be processed further and in any order, as defined by the 857 following subsections. 859 5.3.2.1. Handling Flow Binding Add Requests 861 If the PRO field of the flow identification option is set to 'Add', 862 it indicates a flow binding add request. 864 If the FID field of the flow identification option is already present 865 in the list of flow binding entries for this mobile node, the home 866 agent MUST reject this flow binding add request by copying the flow 867 identification option in the BA, and setting the Status field to 135 868 (FID already in use). 870 If the flow identification option does not include a flow description 871 sub-option, the home agent MUST again reject this request by copying 872 the flow identification option in the BA, and setting the Status 873 field to 129 (Flow identification option poorly formed). 875 If the flow identification option does include a flow description 876 sub-option, but the flow description type is not supported, the home 877 agent MUST also reject this request by copying the flow 878 identification option in the BA, and setting the Status field to 137 879 (FD-Type not supported). 881 If the FID value is new the home agent MUST check the Action field in 882 combination with the Binding Reference sub-option if present. 884 - if the Action indicates 'Forward' 885 If the Binding reference sub-option is not included or if it is 886 included but it contains more than a single BID, the home agent 887 MUST reject this flow binding add request by copying the flow 888 identification option in the BA, and setting the Status field to 889 129 (Flow identification option poorly formed). 891 If the Binding Reference sub-option is present and includes a 892 single BID, but the BID is not present in the binding cache of the 893 mobile node the home agent MUST reject this flow binding add 894 request by copying the flow identification option in the BA, and 895 setting the Status field to TBD (BID not known). 897 If the Binding Reference sub-option is present and includes a 898 single BID, and the BID exists in the mobile node's binding cache, 899 the home agent SHOULD add a new entry in the mobile node's list of 900 flow binding entries, as defined below. 902 - if the Action indicates 'Discard', 904 Any Binding Reference sub-options that might be present SHOULD be 905 ignored. 907 The home agent SHOULD add a new entry in the mobile node's list of 908 flow binding entries, as defined below. 910 - if the Action indicates 'n-cast', 912 If the Binding reference sub-option is not included, the home 913 agent MUST reject this flow binding add request by copying the 914 flow identification option in the BA, and setting the Status field 915 to 129 (Flow identification option poorly formed). 917 If the Binding Reference sub-option is present and includes BIDs 918 that are not present in the binding cache of the mobile node the 919 home agent MUST reject this flow binding add request by copying 920 the flow identification option in the BA, and setting the Status 921 field to TBD (BID not known). 923 If the Binding Reference sub-option is present and includes one or 924 more BIDs, and the BIDs exist in the mobile node's binding cache, 925 the home agent SHOULD add a new entry in the mobile node's list of 926 flow binding entries, as defined below. 928 When the home agent decides to add an entry in the mobile node's list 929 of flow binding entries, as discussed above, it MUST do it according 930 to the following rules: The entry MUST be placed according to the 931 order indicated by the FID-PRI field of the flow identification 932 option and it MUST include: 934 the FID as a key to the entry 936 The flow description included in the corresponding sub-option 938 the action indicated in the Action field 940 the BIDs indicated in the binding reference sub-option 942 the entry MUST be marked as Active, as shown in Section 4.4 944 5.3.2.2. Handling flow binding Modification Requests 946 If the PRO field of the flow identification option is set to 947 'Modify', it indicates a flow binding modification request. 949 Note that flow binding modification is essentially a process where an 950 existing flow binding is removed from the list of flow binding 951 entries and a new flow binding (included in the option) is added, and 952 given the same FID as the flow that was removed. 954 If the value of the FID field of the flow identification option is 955 not present in the binding cache entries for this mobile node, the 956 home agent MUST reject this flow binding modify request by copying 957 the flow identification option in the BA, and setting the Status 958 field to 135 (FID not found). 960 If the value of the FID field is present in the mobile nodes list of 961 flow binding entries, the home agent SHOULD first remove the flow 962 binding entry identified by the FID. The home agent then SHOULD 963 processes this flow identification option as defined in 964 Section 5.3.2.1. 966 5.3.3. Receiving BU with Flow Summary Option 968 When the home agent receives a binding update which includes a Flow 969 Summary option, it first performs the operation described in section 970 10.3.1 of RFC3775. Binding update messages including more than one 971 flow summary option MUST be rejected. 973 Home agents that do not support this specification will ignore the 974 flow summary option, having no effect on the operation of the rest of 975 the protocol. 977 If the value of any of the FID fields included in the flow summary 978 option is not present in the list of flow binding entries for this 979 mobile node, the home agent MUST reject this flow binding modify 980 request by including a flow identification option in the BA, and 981 setting the FID field in the value of the FID that is not found and 982 the Status field to 135 (FID not found). 984 If the value of the FID field is present in the mobile nodes list of 985 slow binding entries the, home agent SHOULD refresh the binding entry 986 identified by the FID without changing any of the other parameters 987 associated with it. 989 5.3.4. Handling flow binding Removals 991 Removal of flow bindings is performed implicitly by omission of a 992 given FID from a binding update. 994 When a valid binding update is received, any registered FIDs that are 995 not explicitly referred to in a flow identification option or in a 996 flow summary option, MUST be removed from the list of flow binding 997 entries for the mobile node. 999 5.3.5. Sending Binding Acknowledgements 1001 Upon the reception of a binding update, the home agent is required to 1002 send back a Binding Acknowledgment. The status code in the Binding 1003 Acknowledgement must be set as recommended in [RFC3775]. This status 1004 code does not give information on the success or failure of flow 1005 bindings. 1007 In order to inform the mobile node about the status of the flow 1008 binding(s) requested by a mobile node, flow identification options 1009 MUST be included in the Binding Acknowledgement message. 1010 Specifically, the home agent MUST copy each flow identification 1011 option received in the binding update and set its status code to an 1012 appropriate value. If an operation requested in a flow 1013 identification option by a mobile node is performed successfully by 1014 the home agent, the status field on the copied flow identification 1015 option in the BA, SHOULD be set to 0 (Flow binding successful), 1016 otherwise it SHOULD be set to one of the rejection codes defined. 1017 Section 5.3.2 identifies a number of cases where specific error codes 1018 should be used. 1020 Home agents that support this specification MAY refuse to maintain 1021 flow bindings by setting the status field of any flow identification 1022 options to 130 (Administratively prohibited), or by just ignoring all 1023 the flow binding options. 1025 Note that BID options and their Status field are handled as defined 1026 in [I-D.ietf-monami6-multiplecoa]. 1028 5.3.6. Packet Processing 1030 This section defines packet processing rules according to this 1031 specification. This specification does not change any of the packet 1032 interception rules defined in [RFC3775], and 1033 [I-D.ietf-mext-nemo-v4traversal]. These rules apply to HAs, MAPs, 1034 and CNs, as part of the routing process for any packet with 1035 destination address set to a valid home address of the mobile node. 1036 For nodes other than CNs this also applies to packets with 1037 destination address set to an address under any of the registered 1038 prefixes. These rules apply equally to IPv6 packets as well as to 1039 IPv4 packets when [I-D.ietf-mext-nemo-v4traversal]. 1041 Before a packet is forwarded to the mobile node it MUST be matched 1042 against the ordered list of flow bindings stored in the list of flow 1043 binding entries for this mobile node (see Section 4.4). A match is 1044 attempted with the flow description included in the first line 1045 (highest order) of the table. If the packet matches the flow 1046 description, the action defined by the action parameter of the table 1047 SHOULD be performed. 1049 - if the Action indicates 'Forward' the packet is forwarded to the 1050 care-of address indicated by the BID parameter in the same line of 1051 the table. 1053 - if the Action indicates 'Discard', the packet is silently 1054 discarded 1056 - if the Action indicates 'n-cast', a copy of the packet is 1057 forwarded to each of the care-of addresses associated with the 1058 BIDs indicated in the same line of the table. 1060 If the action indicated in one of the entries in the list of flow 1061 bindings is "Discard" then, no BIDs needs to be indicated in the same 1062 entry since the packet is not forwarded. If, however, the action 1063 indicated in an entry of the list of flow bindings is "forward" or 1064 "n-cast", the entry must indicated a BID. For "n-cast" if any of the 1065 BIDs indicated does not correspond to a valid care-of address, e.g., 1066 the BID was deregistered then that BID has no effect on the traffic. 1067 In other words, packets matching the flow binding are n-casted to the 1068 other BIDs, pointing to registered care-of addresses. If none of the 1069 BIDs pointed to in a flow binding entry is valid then the entry is 1070 considered to be inactive (as defined in Section 4.4) and is skipped. 1071 In other words packets should not be matched against that entry. 1073 6. Security considerations 1075 This draft introduces a new option that adds more granularity to the 1076 binding update message. The new option allows the mobile node to 1077 associate some flows to one interface and other flows to another 1078 interface. Since the flow Identification option is part of the 1079 mobility header, it uses the same security as the Binding Update, 1080 whether it is sent to the home agent, correspondent node, or MAP. 1082 7. IANA Considerations 1084 A Type number (TBD) for Flow Identification Mobility Option and 1085 another Type number (TBD) for Flow Summary Mobility Option has been 1086 registered from the space of numbers for mobility options, defined 1087 for Mobile IPv6 [RFC3775]. This registry is available from 1088 http://www.iana.org under "Mobile IPv6 parameters". 1090 A new sub-type space for the type number of the Flow Identification 1091 Mobility Option has been created: "Flow Identification Mobility 1092 Option Sub-Options". The suboption values 1, and 2, are defined in 1093 this specification, and the values 16-32 are reserved for flow 1094 description sub-options to defined in separate documents. The rest 1095 of the sub-options are reserved and available for allocation based on 1096 Expert Review. 1098 Finally, a new space for the status field of the Flow Identification 1099 Mobility Option has been created: "Flow Identification Mobility 1100 Option Status codes". Values 0, 128-130 and 135-139 are defined in 1101 this specification. The rest of the values below 128 are reserved 1102 for accept codes, and values from 128 and above are reserved for 1103 reject codes. 1105 Similar to the procedures specified for Mobile IPv6 [RFC3775] number 1106 spaces, future allocations from the two number spaces require Expert 1107 Review [RFC5226]. 1109 8. Contributors 1111 We would like to explicitly acknowledge the following person who co- 1112 authored one of the documents used as source material for this 1113 document. 1115 Nikolaus A. Fikouras, niko@comnets.uni-bremen.de 1117 9. Acknowledgements 1119 We would also like to acknowledge the following people in 1120 alphabetical order: C. Castelluccia, K. ElMalki, K. Georgios, , C. 1121 Goerg, T. Noel, F.-N. Pavlidou, V. Park. Gabor Fekete for the 1122 analysis that led to the inclusion of the BIDRef sub-option. Henrik 1123 Levkowetz for suggesting support for other ways of describing flows. 1125 10. References 1127 10.1. Normative References 1129 [I-D.ietf-mext-nemo-v4traversal] 1130 Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1131 Routers", draft-ietf-mext-nemo-v4traversal-10 (work in 1132 progress), April 2009. 1134 [I-D.ietf-monami6-multiplecoa] 1135 Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 1136 and K. Nagami, "Multiple Care-of Addresses Registration", 1137 draft-ietf-monami6-multiplecoa-13 (work in progress), 1138 April 2009. 1140 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1141 Requirement Levels", BCP 14, RFC 2119, March 1997. 1143 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1144 in IPv6", RFC 3775, June 2004. 1146 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1147 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1148 RFC 3963, January 2005. 1150 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1151 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1152 May 2008. 1154 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 1155 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 1156 Management", RFC 5380, October 2008. 1158 10.2. Informative References 1160 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 1161 McManus, "Requirements for Traffic Engineering Over MPLS", 1162 RFC 2702, September 1999. 1164 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1165 RFC 3753, June 2004. 1167 [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support 1168 Terminology", RFC 4885, July 2007. 1170 Authors' Addresses 1172 Hesham Soliman 1173 Elevate Technologies 1175 Email: hesham@elevatemobile.com 1177 George 1178 Qualcomm 1180 Email: tsirtsis@gmail.com 1182 Nicolas Montavont 1183 Institut Telecom / Telecom Bretagne 1184 2, rue de la chataigneraie 1185 Cesson Sevigne 35576 1186 France 1188 Phone: (+33) 2 99 12 70 23 1189 Email: nicolas.montavont@telecom-bretagne.eu 1190 URI: http://www.rennes.enst-bretagne.fr/~nmontavo// 1192 Gerardo 1193 Qualcomm 1195 Email: gerardog@qualcomm.com 1197 Koojana Kuladinithi 1198 University of Bremen 1199 ComNets-ikom,University of Bremen. 1200 Otto-Hahn-Allee NW 1 1201 Bremen, Bremen 28359 1202 Germany 1204 Phone: +49-421-218-8264 1205 Fax: +49-421-218-3601 1206 Email: koo@comnets.uni-bremen.de 1207 URI: http://www.comnets.uni-bremen.de/~koo/