idnits 2.17.1 draft-coras-lisp-re-03.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 : ---------------------------------------------------------------------------- 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 date (July 29, 2013) is 3923 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-farinacci-lisp-mr-signaling-02 == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-te-03 == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-02 ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Coras 3 Internet-Draft A. Cabellos-Aparicio 4 Intended status: Informational J. Domingo-Pascual 5 Expires: January 30, 2014 Technical University of 6 Catalonia 7 F. Maino 8 D. Farinacci 9 cisco Systems 10 July 29, 2013 12 LISP Replication Engineering 13 draft-coras-lisp-re-03 15 Abstract 17 This document describes a method to build and optimize inter-domain 18 LISP router distribution trees for locator-based unicast and 19 multicast replication of EID-based multicast packets. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 30, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 57 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Overlay Signaling . . . . . . . . . . . . . . . . . . . . . . 5 59 4.1. RTR Registration . . . . . . . . . . . . . . . . . . . . . 6 60 4.2. ETR/RTR Subscription . . . . . . . . . . . . . . . . . . . 6 61 4.3. ETR/RTR Unsubscription . . . . . . . . . . . . . . . . . . 7 62 5. Overlay Management . . . . . . . . . . . . . . . . . . . . . . 7 63 5.1. RLOC Failure and Unreachability . . . . . . . . . . . . . 7 64 5.2. Other Overlay Management Considerations . . . . . . . . . 8 65 5.3. Automated Computation of RTR Level . . . . . . . . . . . . 8 66 5.3.1. Algorithm for Computing Optimized Distribution 67 Trees . . . . . . . . . . . . . . . . . . . . . . . . 9 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 74 Appendix A. MADDBST heuristic . . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 The Locator/Identifier Separation Protocol (LISP) [RFC6830] provides 80 the mechanisms for the separation of Location and Identity semantics 81 presently overloaded by IP addresses. The split results in the 82 creation of two namespaces that unambigously identify edge-site 83 network objects, Endpoint IDs (EIDs), and core routing objects, 84 Routing LOCators (RLOCs). Apart from aiding the scalablity of the 85 core routing infrastructure, the decoupling also enables the 86 (re)implementation of new or existing inter-domain routing 87 mechanisms. 89 One such mechanism is inter-domain IP source-specific multicast (SSM) 90 [RFC4607]. In this sense, [RFC6831] defines the procedures carried 91 out for delivering multicast packets from a source host in a LISP 92 site to receivers residing in the same domain or in other LISP or 93 non-LISP sites when an underlying multicast infrastructure exists. 94 The signaling protocol it specifies for conveying (S-EID,G) state and 95 building the distribution tree that connects the source ITR and the 96 receiving ETRs is PIM [RFC4601]. An alternative method that uses 97 Map-Requests for propagating (S-EID,G) state from ETRs to the ITR is 98 established in [I-D.farinacci-lisp-mr-signaling]. 100 Although desirable to use multicast routing in the core network when 101 available, a mismatch between the multicast capabilities of receiver 102 ETRs and source ITR might impede their interconnection. In such a 103 case, unicast RLOC encapsulation is necessary to deliver multicast 104 packets directly to the ETRs. This however leads to high ITR head- 105 end replication for large sets of ETRs. Therefore, to reduce the 106 replication load of the ITR and scale the service with the number of 107 multicast receivers, the ITR may choose to offload replication to a 108 set of RTRs. 110 The current document describes how multicast RTRs can be used to 111 build an inter-domain distribution tree rooted at the ITR that can 112 perform unicast and/or multicast encapsulated replication of 113 multicast packets. This concept, of distributing the replication 114 load from ITR to other RTRs downstream on the core overlay 115 distribution tree, is known as Replication Engineering or LISP-RE. 116 Since unicast replication in such overlays can be suboptimal when 117 compared to the underlay network, methods to optimize packet delivery 118 over the distribution tree are also presented. 120 This specification does not describe how (S-EID,G) state is built in 121 source and receiver domains, nor does it describe how such state is 122 propagated from receiver ETRs to source ITR. This specification 123 defines how (S-EID,G) map-cache state is built in the ITR, RTRs and 124 ETRs participating in the overlay distribution tree when they are not 125 connectable by multicast. 127 2. Definition of Terms 129 The terminology in this document is consistent with the definitions 130 in [RFC6830] and [RFC6831] however, it is extended to account for 131 LISP-RE concepts: 133 Delivery Group (DG): The outer destination address of a multicast 134 encapsulated multicast packet with an EID source. 136 Unicast Replication: Is the notion of replicating a multicast packet 137 with an EID source address at an ITR or RTR by encapsulating it 138 into a unicast packet. That is, the oif-list of a multicast map- 139 cache entry can not only have interfaces present for link-layer 140 replication and multicast encapsulation but also for unicast 141 encapsulation. 143 Overlay Distribution Tree: A degree-constrained spanning tree that 144 represents the path followed by unicast and/or multicast 145 encapsulated multicast packets from the root (ITR) to the leaves 146 (ETRs) through intermediary nodes (RTRs). The ITR and RTRs 147 unicast and/or multicast replicate packets to their tree children. 149 LISP Replication Node: A router (either the ITR or an RTR) 150 participating and replicating packets downstream in the 151 distribution tree. 153 Multicast Ingress Tunnel Router (ITR): An ITR as specificed in 154 [RFC6830] that participates as the root in the distribution tree. 156 Multicast Egress Tunnel Router (ETR): An ETR as specified in 157 [RFC6830] that participates as a leaf in the distribution tree. 158 ETR are the only members of the tree that do not unicast 159 replicate. 161 Multicast Re-encapsulating Tunnel Router (RTR): An RTR as specified 162 in [I-D.farinacci-lisp-te] that participates as an intermediary 163 node in the distribution tree. 165 Replication Target: A multicast channel-id (S-EID,G) or a set of 166 multicast channel-ids (S-EID-prefix,G). 168 Joining-OIF-list: Represents a collection of state per multicast 169 routing table entry at an RTR or ETR that is created by received 170 Map-Request/Join-Request. 172 Forwarding-OIF-list: Represents the outgoing RLOC list a multicast 173 router stores per multicast routing table entry such that it knows 174 to which RLOCs to replicate multicast packets. Although the 175 Joining-OIF-list contains sufficient information to allow the 176 forwarding of encapsulated multicast packets, using it is 177 inefficient. Thereby, an RTR implementation may wish to build an 178 efficient Forwarding-OIF-list. Ways of implementing a Forwarding- 179 OIF-list are out of the scope of this document. 181 Upstream: Towards the root of the tree. 183 Downstream: Away from the root of the tree. 185 3. Overview 187 This specification describes a method to diminish the ITR's 188 replication load by using RTRs to build an inter-domain distribution 189 tree. The tree is managed by the source domain's Map-Server. RTRs 190 join the overlay on manual configuration and advertise to the Map- 191 Server their availability to replicate traffic for a multicast 192 channel (S-EID,G). Out of all the RTRs registering for the same 193 multicast channel, the Map-Server builds one mapping and organizes 194 the RLOCs in a multi-level hierarchy. The hierarchy is rooted at the 195 ITR and computed based on the manually configured information RTRs 196 register or by means of local policy and algorithms. ETRs always 197 join the overlay as leafs and their attachment prompts the creation 198 of a path, which traverses the RTR hierarchy, to the ITR. The path 199 is built at receiver request by incrementally linking all 200 distribution tree levels, starting at the joining ETR up to the 201 source ITR. 203 The way the distribution tree is built has several benefits. First, 204 it ensures that packets in the source domain do not reach the ITR if 205 no ETR is joined. Second, it ensures that packets are forwarded from 206 ITR to all ETRs without mapping database lookups. Finally, the 207 multicast source is allowed to roam since a first level RTR, when 208 informed of the roam event, can do a new database lookup to find the 209 new ITR to join to. 211 4. Overlay Signaling 213 This section describes the signaling the ITR, RTRs and ETRs use in 214 order to participate in the overlay and build a distribution tree. 215 The signaling messages used are described in 216 [I-D.farinacci-lisp-mr-signaling] and [RFC6831]. 218 4.1. RTR Registration 220 RTR participation in the overlay is condition by the configuration of 221 a replication target, a multicast channel (S-EID,G) or set of 222 channels (S-EID-prefix,G), the RTR is to perform replication for. 223 Once configured, manually or by automated mechanisms, an RTR Map- 224 Registers its replication target to the mapping database system with 225 merge-semantics. In the registration it also provides its list of 226 RLOCs to be used by overlay peers and a set of corresponding weights 227 and priorities. If present, information about the level of the 228 hierarchy where the RTR should attach is also conveyed by means of an 229 Replication List Entry canonical address [I-D.ietf-lisp-lcaf]. 231 Due to the merge-semantics, the Map-Server aggregates all RTR 232 originated Map-Register messages in a single, per replication target 233 mapping. If no level information is provided or if so configured, 234 the Map-Server should use local policy to compute a hierarchy and 235 associate a level within it to each entry in the list (more details 236 in Section 5.3). It should be noted that the entries of the 237 resulting mapping are not RLOCs but Replication List entries. 239 4.2. ETR/RTR Subscription 241 When an ETR creates (S-EID,G) state from a site based multicast join, 242 i.e., its oif-list goes non-empty, it must send an upstream Join 243 request. If the ETR does not have multicast connectivity to its 244 upstream and unicast replication must be performed, the ETR requests 245 that a path from ITR to itself, over the RTR hierarchy be 246 constructed. The following procedure is followed to build the path: 248 1. ETR sends a Map-Request/Join-Request for (S-EID,G) multicast 249 channel to the mapping database system. 251 2. The Map-Server receives the request and looks up the mapping 252 associated to (S-EID,G). Out of the distribution tree hierarchy 253 encoded within the mapping, the Map-Server selects a set of leaf 254 RTRs, i.e., members of the level furthest away from the ITR, and 255 builds with them a new mapping for (S-EID,G) that it conveys to 256 the ETR in a Map-Reply. 258 3. From the list it receives, the ETR selects the best RLOC 259 according to local policy, taking into account the priorities and 260 weights. It then sends a Map-Request/Join-Request for (S-EID,G) 261 to the RTR that registered the selected RLOC. If the ETR has 262 multiple RLOCs it may convey them all encoded in the Map-Reply 263 field of the Map-Request/Join-Request together with associated 264 priorities and weights. 266 4. The RTR stores the ETR's subscription information in the join- 267 oif-list associated to (S-EID,G) and inserts the RLOC obtained 268 after evaluating the priorities and weights in the oif-list for 269 (S-EID,G). It then confirms the ETR's subscription with a Map- 270 Reply. 272 5. If not already a member of (S-EID,G), the RTR initiates it's own 273 attachment to the distribution tree by repeating the steps 1-4. 274 An important difference at step 2, the Map-Server replies to a 275 joining RTR with a list of RTRs in the adjacent upstream layer, 276 as opposed to a list of leaf RTRs, like in the case of an ETR 277 join. This procedure may recurse upstream up to when the ITR or 278 an RTR already attached to the distribution tree is joined. On 279 completion, there should exist a path from ITR to joining ETR. 281 6. If the ITR is already member of (S-EID,G) the process stops. 282 Otherwise, the ITR sends a PIM join to the intra-domain multicast 283 source ensuring the creation of a path from the multicast source 284 to the receiver end-hosts. 286 If at any point, when creating a link between two adjacent layers, 287 multicast replication can be performed, instead of unicast one, the 288 router joining its upstream can set as source of the Map-Request/ 289 Join-Request a delivery group. 291 4.3. ETR/RTR Unsubscription 293 When an ETR's oif-list goes empty a Map-Request/Leave-Request is sent 294 to the upstream RTR which will result in the removal of the ETR's 295 associated entry from the RTR's oif-list. The procedure is repeated 296 by the RTR, and it may recurse upstream, if its own oif-list also 297 goes empty. 299 When an RTR departs, it should first change the priority of the RLOCs 300 it registers with the Map-Server to 255 and set its locators as 301 unreachable in the RLOC-Probing replies it sends downstream. 302 Finally, once all adjacent lower level members have sent Map-Request/ 303 Leave-Request messages the RTR can stop registering (S-EID,G) with 304 the mapping database system and thus leave the overlay. 306 5. Overlay Management 308 5.1. RLOC Failure and Unreachability 310 RLOC failure is detected at control-plane level through RLOC-probing 311 [RFC6830] by both upstream and downstream routers. When an RTR 312 detects the failure of an downstream RLOC, it ceases replicating 313 towards it. The affected RLOC is removed from the forwarding-oif- 314 list and marked as unreachable in the join-oif-list. If a backup 315 RLOC was provided by the downstream router in the Map-Request/ 316 Join-Request, it is instead inserted in the forwarding-oif-list and 317 the failure results in no packet loss. 319 The routers downstream of a failed RTR RLOC, or who lost connectivity 320 to said RLOCs, remove their Map-Request/Join-Request associated state 321 and reperform the join procedure. Packet loss in this case must be 322 solved by out-of-band mechanisms that are out of the scope of the 323 current document. 325 5.2. Other Overlay Management Considerations 327 An overloaded RTR, i.e., one whose fan-out can not be increased, 328 should change the priority of the RLOCs it registers with the mapping 329 database system to 255. In such a situation, the Map-Server updates 330 the associated mapping and informs all routers having requested it 331 about the change through solicit Map Request (SMR) messages. Both 332 new ETRs attaching to the distribution tree and those already 333 connected but reperforming the join procedure must not use the RLOCs 334 with a priority of 255 as specified in [RFC6830]. However, routers 335 having performed Join-Requests prior to the change should not break 336 their existing connections to the affected RTR. 338 All routers part of an (S-EID,G) multicast channel should re-evaluate 339 their attachment point to the distribution tree whenever the Map- 340 Server updates the associated mapping. This ensures the overlay 341 member routers attach to the best suited parent when new RTRs join or 342 previously attached ones stop being overloaded. Change of a parent 343 should be done following a "make before break" procedure. 344 Specifically, the router changing attachment point first connects to 345 the new parent and only afterwards sends the Leave-Request. 347 When a downstream RTR subscribes to a set of channel-ids (S-EID- 348 prefix,G) using multiple RLOCs in a load-balancing configuration, the 349 upstream RTR may choose to load-split channel-ids (S-EID,G) over the 350 given set of RLOCs. 352 5.3. Automated Computation of RTR Level 354 Operators wishing to automate the RTR joining procedure may wish to 355 use an algorithm for computing an optimized distribution tree. The 356 algorithm could be implemented in the Map-Server and its output 357 should be used to associate to all RTRs a level in the distribution 358 tree. Due to the centralized management, on-line switching between 359 algorithms may be possible in accordance to the required distribution 360 tree performance. However, their use of such algorithms is dependent 361 on the presence of overlay topological information. Ways of 362 obtaining topological information will be discussed in future 363 versions of this document. 365 5.3.1. Algorithm for Computing Optimized Distribution Trees 367 The current document does not recommend an algorithm for computing 368 optimized distribution trees. However, it provides as an example a 369 low computation cost heuristic, which, in the scenarios simulated in 370 [LCAST-TR], can produce latencies between the ITR and the multicast 371 receivers close to unicast ones. Its choice is to be influenced by 372 operational requirements and the hardware constraints of the 373 equipment in charge of running it. Future experiments might result 374 in a recommendation. 376 In what follows, we use the term "distance" when referring to a 377 relative length or amplitude of a metric, observed on a path 378 connecting two points, but when the exact nature of the metric is of 379 no interest. 381 Considering as goal the delivery of content for delay sensitive 382 applications, the function the algorithm minimizes is the maximum 383 distance (e.g. latency or number of AS hops) from a multicast 384 receiver to the ITR source. Notice that the reference is the 385 multicast receiver host and not an ETR. Thus, what matters in 386 deciding a member's position in the distribution tree is not solely 387 its distance to the ITR but also the number of multicast receivers it 388 serves. Then, a router close to the source but serving few receivers 389 might find itself lower in the distribution tree than another with a 390 slightly higher distance to the source but with a larger receiver 391 set. The algorithm optimizes the quality of experience for multicast 392 receivers and not for tunnel routers. 394 The problem described above, that searches for a minimum average 395 distance, degree-bounded spanning tree (MADDBST), can be formally 396 stated as: 398 Definition: Given an undirected complete graph G=(V,E), a designated 399 vertex r belonging to V, for all vertices v in V, a degree bound 400 d(v) <= dmax, dmax a positive integer, a vertex weight function 401 c(v) with positive integer values, and an edge weight function 402 w(e) with positive values, for all edges e in E. Let W(r,v,T) 403 represent the cost of the path linking r and v in the spanning 404 tree T. Find the spanning tree T of G, routed at r, satisfying 405 that d(v) <= dmax and the distance to the source per multicast 406 receiver is minimized. 408 The heuristic used to solve this problem works by incrementally 409 growing a tree, starting at the root node r, until it becomes a 410 spanning tree. For each node v, not yet a tree member, it selects a 411 potential parent node u in the tree T, such that the distance per 412 receiver to r, is minimized. At each step, the node with the 413 smallest metric value is added to the tree and the parent selection 414 is redone. The pseudocode of the heuristic is provided in 415 Appendix A. 417 [SHI] and [BAN] have previously defined and solved similar 418 optimization problems. Shi et al. [SHI] also prove that a 419 particular instance of the problem, where all vertices have weight 1, 420 is NP-complete for degree constraints 2 <= dmax <= |V|-1. 422 The algorithm can optimize an unicast overlay however, it should not 423 be used to optimize multicast underlay delivery. As a result, if 424 multicast is used as underlay between part of the overlay members, 425 once one of the members of such Delivery Group is added to the 426 distribution tree, the others should be marked as attached also. 427 These nodes should receive multicast encapsulated multicast packets 428 from the chosen node over the underlying multicast distribution tree. 430 Finally, since the RTRs do not replicate packets for multicast 431 receiver hosts, prior to applying the MADDBST heuristic, a Minimum 432 Spanning Tree (MST) algorithm should be used to compute the RTR 433 distribution tree. In this case, the MADDBST heuristic should start 434 attaching ETRs having as input the tree resulting from MST. 436 6. Security Considerations 438 Security concerns for LISP-RE the same as for [RFC6831] and 439 [I-D.farinacci-lisp-mr-signaling]. 441 7. IANA Considerations 443 This memo includes no request to IANA. 445 8. Acknowledgements 447 TODO 449 9. References 450 9.1. Normative References 452 [I-D.farinacci-lisp-mr-signaling] 453 Farinacci, D. and M. Napierala, "LISP Control-Plane 454 Multicast Signaling", draft-farinacci-lisp-mr-signaling-02 455 (work in progress), July 2013. 457 [I-D.farinacci-lisp-te] 458 Farinacci, D., Lahiri, P., and M. Kowal, "LISP Traffic 459 Engineering Use-Cases", draft-farinacci-lisp-te-03 (work 460 in progress), July 2013. 462 [I-D.ietf-lisp-lcaf] 463 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 464 Address Format (LCAF)", draft-ietf-lisp-lcaf-02 (work in 465 progress), March 2013. 467 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 468 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 469 Protocol Specification (Revised)", RFC 4601, August 2006. 471 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 472 IP", RFC 4607, August 2006. 474 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 475 Locator/ID Separation Protocol (LISP)", RFC 6830, 476 January 2013. 478 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 479 Locator/ID Separation Protocol (LISP) for Multicast 480 Environments", RFC 6831, January 2013. 482 9.2. Informative References 484 [BAN] Banerjee, S., Kommareddy, C., Kar, K., Bhattacharjee, B., 485 and S. Khuller, "Construction of an efficient overlay 486 multicast infrastructure for real-time applications", 487 INFOCOM , 2002. 489 [LCAST-TR] 490 Coras, F., Cabellos, A., Domingo, J., Maino, F., and D. 491 Farinacci, "Inter-Domain Multicast: LISP Edge Based 492 Trees", Technical 493 Report http://personals.ac.upc.edu/fcoras/lcast-tr.pdf, 494 2012. 496 [SHI] Shi, S., Turner, J., and M. Waldvogel, "Dimensioning 497 server access bandwidth and multicast routing in overlay 498 networks", NOSSDAV , 2001. 500 Appendix A. MADDBST heuristic 502 INPUT: G = (V,E); r; dmax; w(u,v); c(v); u, v in V 503 OUTPUT: T 505 FOREACH v in V DO 506 delta(v) = w(r,v)/c(v); 507 p(v) = r; 508 END FOREACH 510 T takes (U = {r}, D={}); 511 WHILE U != V DO 512 LET u in U-V be the vertex with the smallest delta(u); 513 U = U U {u}; L = L U {(p(u),u)}; 514 FOREACH v in V-U DO 515 delta(v) = infinity; 516 FOREACH u in U DO 517 IF d(u) < dmax and 518 W{r,u,T} + w(u,v)/c(v) < delta(v) THEN 519 delta(v) = W{r,u,T} + w(u,v)/c(v); 520 p(v) = u; 521 END IF 522 END FOR 523 END FOR 524 END WHILE 526 Figure 1 528 Authors' Addresses 530 Florin Coras 531 Technical University of Catalonia 532 C/Jordi Girona, s/n 533 BARCELONA 08034 534 Spain 536 Email: fcoras@ac.upc.edu 537 Albert Cabellos-Aparicio 538 Technical University of Catalonia 539 C/Jordi Girona, s/n 540 BARCELONA 08034 541 Spain 543 Email: acabello@ac.upc.edu 545 Jordi Domingo-Pascual 546 Technical University of Catalonia 547 C/Jordi Girona, s/n 548 BARCELONA 08034 549 Spain 551 Email: jordi.domingo@ac.upc.edu 553 Fabio Maino 554 cisco Systems 555 Tasman Drive 556 San Jose, CA 95134 557 USA 559 Email: fmaino@cisco.com 561 Dino Farinacci 562 cisco Systems 563 Tasman Drive 564 San Jose, CA 95134 565 USA 567 Email: farinacci@gmail.com