idnits 2.17.1 draft-ietf-dhc-dhcpv6-ldra-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 : ---------------------------------------------------------------------------- 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 (June 8, 2010) is 5070 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-06) exists of draft-ietf-dhc-l2ra-04 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group D. Miles, Ed. 3 Internet-Draft S. Ooghe 4 Intended status: Standards Track Alcatel-Lucent 5 Expires: December 10, 2010 W. Dec 6 Cisco Systems 7 S. Krishnan 8 A. Kavanagh 9 Ericsson 10 June 8, 2010 12 Lightweight DHCPv6 Relay Agent 13 draft-ietf-dhc-dhcpv6-ldra-02 15 Abstract 17 This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that 18 is used to insert relay agent options in DHCPv6 message exchanges 19 identifying client-facing interfaces. The LDRA can be implemented in 20 existing access nodes (such as DSLAMs and Ethernet switches) that do 21 not support IPv6 control or routing functions. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 10, 2010. 40 Copyright Notice 42 Copyright (c) 2010 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 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Server Considerations . . . . . . . . . . . . . . . . . . . . 4 62 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5.1. Relay-Forward Message . . . . . . . . . . . . . . . . . . 5 64 5.2. Relay-Reply Message . . . . . . . . . . . . . . . . . . . 5 65 5.3. Mandatory DHCP Options . . . . . . . . . . . . . . . . . . 6 66 5.3.1. Relay-Message Option . . . . . . . . . . . . . . . . . 6 67 5.3.2. Interface-ID Option . . . . . . . . . . . . . . . . . 6 68 6. Agent Behaviour . . . . . . . . . . . . . . . . . . . . . . . 7 69 6.1. Relaying a Client Message . . . . . . . . . . . . . . . . 7 70 6.1.1. Client Message Validation . . . . . . . . . . . . . . 7 71 6.1.2. Trusted and Untrusted Interfaces . . . . . . . . . . . 8 72 6.2. Relaying a Relay-Reply message from the network . . . . . 8 73 7. Network Topology . . . . . . . . . . . . . . . . . . . . . . . 9 74 7.1. Client and Server on Same Link . . . . . . . . . . . . . . 9 75 7.2. Client and Server behind Relay Agent . . . . . . . . . . . 10 76 7.3. Relay Agent in Front of LDRA . . . . . . . . . . . . . . . 11 77 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 82 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 85 1. Introduction 87 DHCPv6 Relay-Agents [RFC3315] are deployed to forward DHCPv6 messages 88 between clients and servers when they are not on the same IPv6 link 89 and are often implemented alongside a routing function in a common 90 node. A Lightweight DHCPv6 Relay Agent (LDRA) allows Relay Agent 91 Information to be inserted by an access node that performs a link- 92 layer bridging (i.e. non-routing) function. A LDRA resides on the 93 same IPv6 link as the client and a DHCPv6 Relay Agent or Server and 94 is functionally the equivalent of the Layer 2 DHCP Relay draft[L2RA] 95 proposed for DHCPv4 operation. 97 Unlike a DHCPv6 Relay-Agent specified in [RFC3315], a LDRA does not 98 implement any IPv6 control functions (e.g. ICMPv6) or have any 99 routing capability in the node. 101 1.1. Requirements Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 2. Background 109 A variety of different link-layer network topologies exist for the 110 aggregation of IPv6 nodes into one or more routers. In Layer 2 111 aggregation networks (IEEE 802.1D bridging or similar) that have many 112 nodes on a single link, a DHCPv6 server or DHCP relay agent would 113 normally be unaware of how a DHCP client is attached to the network. 114 The LDRA allows Relay Agent Information, including the Interface-ID 115 option [RFC3315], to be inserted by the access node so that it may be 116 used by the DHCPv6 server for client identification. A typical 117 application in a broadband service provider may be as an equivalent 118 to the Broadband Forum TR-101 Layer 2 DHCP Relay Agent [TR-101] 119 described in [L2RA]. 121 3. Terminology 123 Access Node A device that combines many interfaces onto 124 one link. An access node is not IP-aware 125 in the data path. 127 Address An IP layer identifier for an interface or 128 set of interfaces. 130 Client-facing An interface on the access node that 131 carries traffic towards the DHCPv6 client. 133 Host A non-routing IPv6 node that is 134 participating in a DHCPv6 message exchange. 136 IP Internet Protocol Version 6 (IPv6). 138 LDRA Lightweight DHCPv6 Relay Agent. 140 Lightweight Relay Agent A function on the access node that 141 intercepts DHCP messages between clients 142 and servers. The function exists as a bump 143 in the wire on the IP link. 145 Link A communication facility or medium over 146 which nodes can communicate at the link 147 layer. 149 Link-local address An IP address having only local-scope, 150 indicated by having the address prefix 151 FE80::/10, that can be used to reach 152 neighbouring nodes attached to the same 153 link. Every interface has a link-local 154 address. 156 Network-facing An interface on the access node that 157 carries traffic towards the DHCPv6 158 server(s). 160 Node A device that implements IPv6. 162 Router A node that forwards packets not directly 163 addressed to itself. 165 Relay Agent A node that acts as an intermediary to 166 deliver DHCP messages between clients and 167 servers and being on the same link as the 168 client. 170 Unspecified address An IPv6 address that is comprised entirely 171 of zeros. 173 4. Server Considerations 175 This document updates the behavior specified in section 11 of DHCP 176 for IPv6 [RFC3315]. RFC3315 states, in part: 178 o If the server receives the message from a forwarding relay agent, 179 then the client is on the same link as the one to which the 180 interface, identified by the link-address field in the message 181 from the relay agent, is attached. 183 DHCP server implementations conforming to this specification must, 184 for the purposes of address selection, ignore any link-address field 185 whose value is zero. In the text from RFC3315 above, "link-address" 186 refers both to the link-address field of the Relay-forward message, 187 and also the link-address fields in any Relay-forward messages that 188 may be nested within the Relay-forward message. 190 5. Message Format 192 The Lightweight DHCPv6 Relay Agent (LDRA) exchanges DHCP messages 193 between clients and servers using the message formats established in 194 [RFC3315]. 196 To maintain interoperability with existing DHCP relays and servers 197 the message format is unchanged from [RFC3315]. The LDRA implements 198 the same message types as a normal DHCPv6 Relay Agent. They are: 200 o Relay-Forward Messages 202 o Relay-Reply Messages 204 5.1. Relay-Forward Message 206 The Relay-Forward message is created by any DHCPv6 Relay Agent, 207 including an LDRA, to forward messages between clients and servers or 208 other relay agents. These messages are built as specified in . 209 [RFC3315]. 211 The Relay-Forward message contains relay agent parameters that 212 identify the client-facing interface on which any reply messages 213 should be forwarded. These parameters are link-address, peer-address 214 and Interface-ID. The link-address parameter MUST be set to the 215 unspecified address. The Interface-ID Relay Agent Option MUST be 216 included in the Relay-Forward message. The LDRA MAY insert 217 additional relay agent options. 219 5.2. Relay-Reply Message 221 The Relay-Reply message is constructed by a DHCPv6 server to send 222 parameters to a DHCP client when a relay agent is present between the 223 server and the client. The Relay-Reply message may be sent after an 224 initial Relay-Forward message as the parameters link-address, peer- 225 address, Interface-ID and the relay agent's IP address are learnt 226 from the Relay-Forward message. 228 The server MUST include the Interface-ID option in the Relay-Reply 229 Message to indicate to the LDRA the interface on which the de- 230 capsulated message should be forwarded. 232 5.3. Mandatory DHCP Options 234 Parameters are exchanged between DHCP client, relay-agent and server 235 through the use of DHCP options. There is a set of mandatory DHCP 236 options that MUST be included by the LDRA in all Relay-Forward 237 messages. These are the: 239 o Relay-Message Option 241 o Interface-ID Option 243 5.3.1. Relay-Message Option 245 A DHCPv6 Relay Agent relays messages between clients and servers or 246 other relay agents through Relay-Forward and Relay-Reply message 247 types. The original client DHCP message (i.e. the packet payload, 248 excluding UDP and IP headers) is encapsulated in a Relay Message 249 option [RFC3315]. 251 As an LDRA does not implement ICMPv6, fragmentation of Relay-Messages 252 is not supported. If a Relay-Message would exceed the MTU of the 253 outgoing interface it MUST be discarded and an error condition SHOULD 254 be logged. 256 5.3.2. Interface-ID Option 258 The LDRA MUST include the Interface-ID option [RFC3315] in all Relay- 259 Forward messages. When a LDRA receives a Relay-reply message with an 260 Interface-ID option present and link-address unspecified, the LDRA 261 MUST relay the decapsulated message to the client on the interface 262 identified in the Interface-ID option. 264 Servers MAY use the Interface-ID for parameter assignment policies. 265 The format of the Interface-ID is outside the scope of this 266 contribution. The Interface-ID SHOULD be considered an opaque value, 267 i.e. the server SHOULD NOT try to parse the contents of the 268 Interface-ID option. The LDRA SHOULD use the same Interface-ID value 269 for a given interface, and this value SHOULD be retained across 270 restarts. This is because, if the Interface-ID changes, a server 271 will not be able to use it reliably in parameter assignment policies. 273 6. Agent Behaviour 275 The LDRA MUST have each of its interfaces configured as either 276 client-facing or network-facing. The LDRA uses the notion of client- 277 facing and network-facing interfaces to process DHCPv6 messages. 279 6.1. Relaying a Client Message 281 When a DHCPv6 message (defined in [RFC3315]) is received on any 282 client-facing interface, the LDRA MUST intercept and process the 283 message. The LDRA MUST also prevent the original message from being 284 forwarded on the network facing interface. 286 The lightweight relay agent adds any other options it is configured 287 or required to include in the Relay-Forward message. The LDRA MUST 288 set the link-address field of the Relay-forward message to the 289 Unspecified Address (::) and MUST include the Interface-ID option in 290 all DHCP Relay-Forward messages. 292 If the message received on the client-facing interface is a Relay- 293 Forward message, the LDRA MUST set the Hop-Count field in the newly 294 created Relay-Forward message to the value of the hop-count field in 295 the received message incremented by 1 as specified in [RFC3315]. 297 The LDRA MUST copy the IP destination and link-layer destination 298 addresses from the client-originated message into the IP destination 299 address and link-layer destination address of the Relay-forward 300 message. 302 The LDRA MUST copy the IP source address from the client-originated 303 message into the peer-address field of the Relay-forward message. 304 The LDRA MUST copy the link-layer source address from the client- 305 originated message into the link-layer source address of the Relay- 306 forward message. 308 6.1.1. Client Message Validation 310 On receipt of a DHCP message on a client-facing interface, the LDRA 311 MUST discard a message if it is of one of following message types: 313 o ADVERTISE (2) 315 o REPLY (7) 317 o RECONFIGURE (10) 319 o RELAY-REPLY (13) 320 Options contained in the DHCPv6 message MUST NOT be validated by the 321 LDRA, making it the responsibility of the DHCP server to check 322 message option validity and allow new options to be introduced 323 without changes on the LDRA. 325 6.1.2. Trusted and Untrusted Interfaces 327 In [RFC3046] DHCPv4 relay-agents had their client-facing interfaces 328 set to trusted and untrusted. An LDRA MUST implement a configuration 329 setting for all client-facing interfaces, marking them either as 330 trusted or as untrusted. This setting SHOULD be configurable per 331 interface. When a client-facing interface is deemed untrusted the 332 LDRA MUST discard any message received from the client-facing 333 interface of type RELAY-FORWARD (12). 335 In DHCPv4 it was not possible for a DHCP server to determine whether 336 the client or an intermediate relay agent had added relay agent 337 options and thus trusted interfaces (relay-agent interfaces that 338 would allow any DHCP options to be present on incoming messages) and 339 untrusted interfaces (relay-agent interfaces that would ensure there 340 are no relay-agent options on incoming messages) were defined. In 341 DHCPv6, relay agents encapsulate the received message into the Relay- 342 Message Option in addition to adding any relay-agent options. This 343 nested message behaviour allows a server to identify the options each 344 relay-agent has inserted along the path, whenever the data path 345 between LDRA and server falls within a protected or operator 346 controlled environment. 348 When an LDRA is deployed, DHCPv6 servers MAY be configured with the 349 Relay-Forward hop-count of the LDRA to instruct them at which level 350 of nesting the relay-agent options should be parsed. This removes 351 the need for an interface to be configured as trusted or untrusted by 352 providing the DHCPv6 server with an awareness of the LDRA logical 353 location in the DHCP relay path. This behaviour is dependent on the 354 interception of all DHCP messages by the LDRA and the incrementing of 355 the Relay-Forward hop-count if a Relay-Forward message is received 356 from the client-facing LDRA interface. 358 6.2. Relaying a Relay-Reply message from the network 360 The LDRA MUST intercept and process all IP traffic received on the 361 network-facing interface that has: 363 o a link-local scoped source address; 365 o a link-local scoped destination address; 366 o protocol type UDP; and 368 o destination port 547 370 An LDRA MUST inspect the DHCP message type and MUST silently discard 371 any DHCP message that is not type Relay-Reply or is otherwise an 372 invalid DHCPv6 packet. The LDRA SHOULD ignore any message that does 373 not meet this criteria and subject it to normal packet forwarding. 375 The Relay-Reply message is considered valid by the LDRA if it passes 376 the validity checks to be performed by a relay agent per [RFC3315] 377 and: 379 - The Interface-ID Option is present and the value corresponds to a 380 valid interface in the access node, 382 - the Relay-Reply peer-address and the destination IP address is 383 identical and it is a link-local scoped address when no IP address is 384 configured on the LDRA, and 386 - the link-address is the Unspecified Address when no IP address is 387 configured on the LDRA 389 The LDRA copies the peer-address into to the destination IP address 390 field. The LDRA SHOULD forward the packet to the correct client- 391 facing interface using the destination link-layer (MAC) address or 392 the Interface-Id in the Relay-Reply. The LDRA SHOULD NOT retransmit 393 the packet on any other interface. The contents of the Relay Message 394 Option is put into an IP/UDP packet and then forwarded to the client. 396 The LDRA MUST copy the link-layer and IP source address from the 397 Relay-Reply message into the IP/UDP packet that is forwarded to the 398 client. 400 7. Network Topology 402 The LDRA intercepts any DHCPv6 message received on client-facing 403 interfaces with a destination IP address of 404 All_DHCP_Relay_Agents_and_Servers (FF02::1:2). The LDRA MUST NOT 405 forward the original client message to a network-facing interface, it 406 MUST process the message and add the appropriate Relay-Forward 407 options as described in previous sections. 409 7.1. Client and Server on Same Link 411 The access node acts as a bridge; it has no information about any IP 412 prefixes that are valid on the link, thus a server should consider 413 address and parameter assignment as if the client DHCP message was 414 not relayed. 415 +--------+ 416 Client -------| | 417 | Access | 418 Client -------| Node |-----+ 419 | (LDRA) | | 420 Client -------| | | 421 +--------+ | 422 | +--------+ 423 |------| Server | 424 | +--------+ 425 +--------+ | 426 Client -------| | | 427 | Access | | 428 Client -------| Node |-----+ 429 | (LDRA) | 430 Client -------| | 431 +--------+ 433 <--------- IPv6 Link --------> 435 For example, if a client sent a DHCP solicit message that was relayed 436 by the LDRA to the server, the server would receive the following 437 Relay-Forward message from the LDRA: 439 src-ip: client link-local address 440 dst-ip: All_DHCP_Relay_Agents_and_Servers 441 msg-type: RELAY-FORWARD 442 hop-count: 0 443 link-address: Unspecified_Address 444 peer-address: client link-local address 445 Interface-ID Option: 446 interface-id: LDRA-inserted interface-id 447 Relay-Message Option, which contains: 448 msg-type: SOLICIT 449 Solicit Message Options: 451 7.2. Client and Server behind Relay Agent 453 The client and server are on different IPv6 links, separated by one 454 or more relay agents that will typically act as a router. The LDRA 455 will send Relay-Forward messages upstream towards the second relay 456 agent which in turn will process the messages. 458 +--------+ 459 Client -------| | 460 | Access | 461 Client -------| Node |-----+ 462 | (LDRA) | | 463 Client -------| | | 464 +--------+ | 465 | +--------+ +--------+ 466 |------| RelayB |-------| Server | 467 | +--------+ +--------+ 468 +--------+ | 469 Client -------| | | 470 | Access | | 471 Client -------| Node |-----+ 472 | (LDRA) | 473 Client -------| | 474 +--------+ 476 <------- IPv6 Link A -------> <--IPv6 Link B--> 478 For example, if a client sent a DHCP solicit message that was relayed 479 by the LDRA to another relay agent and then to the server, the server 480 would receive the following Relay-Forward message from the LDRA: 482 src-ip: relayB 483 dst-ip: server 484 msg-type: RELAY-FORWARD 485 hop-count: 1 486 link-address: relayB address from link A 487 peer-address: client link-local address 488 Relay-Message Option, which contains: 489 msg-type: RELAY-FORWARD 490 hop-count: 0 491 link-address: Unspecified_Address 492 peer-address: client link-local address 493 Interface-ID Option: 494 interface-id: LDRA-inserted interface-id 495 Relay-Message Option, which contains: 496 msg-type: SOLICIT 497 Solicit Message Options: 499 7.3. Relay Agent in Front of LDRA 501 The client and server are on different IPv6 links, separated by one 502 or more relay agents that will typically act as a router and there is 503 an [RFC3315] Relay Agent on the client-facing Interface of the LDRA. 504 The LDRA will send Relay-Forward messages upstream towards the second 505 relay agent which in turn will process the messages. 507 +--------+ 508 RelayC -------| | 509 | Access | 510 RelayC -------| Node |-----+ 511 | (LDRA) | | 512 RelayC -------| | | 513 +--------+ | 514 | +--------+ +--------+ 515 |------| RelayB |-------| Server | 516 | +--------+ +--------+ 517 +--------+ | 518 RelayC -------| | | 519 | Access | | 520 RelayC -------| Node |-----+ 521 | (LDRA) | 522 RelayC -------| | 523 +--------+ 525 <------- IPv6 Link A -------> <--IPv6 Link B--> 527 For example, if a client sent a DHCP solicit message that was relayed 528 by RelayC and the LDRA to another relay agent, RelayB, and then to 529 the server, the server would receive the following Relay-Forward 530 message: 532 src-ip: relayB 533 dst-ip: server 534 msg-type: RELAY-FORWARD 535 hop-count: 2 536 link-address: relayB address from link A 537 peer-address: relayC 538 Relay-Message Option, which contains: 539 msg-type: RELAY-FORWARD 540 hop-count: 1 541 link-address: Unspecified_Address 542 peer-address: relayC 543 Interface-ID Option: 544 interface-id: LDRA-inserted interface-id 545 Relay-Message Option, which contains: 546 msg-type: RELAY-FORWARD 547 hop-count: 0 548 link-address: global or unspecified address 549 peer-address: end client address 550 Interface-ID Option: (if required) 551 interface-id: relayC inserted Interface-ID 552 Relay-Message Option, which contains: 553 msg-type: SOLICIT 554 Solicit Message Options: 556 8. Contributors 558 The authors would like to thank the following for their support, 559 Lieven Levrau, Alastair Johnson, Robert Haylock, Mickey Vucic, Ludwig 560 Pauwels, Fernando Cuervo, John Kaippallimalil, Fredrik Garneij, 561 Alfred Hoenes and Ted Lemon. 563 Comments are solicited and should be addressed to the DHC WG mailing 564 list (dhcwg@ietf.org) and/or the author. 566 9. IANA Considerations 568 This document does not introduce any new namespaces for the IANA to 569 manage. 571 10. Security Considerations 573 Although the LDRA only listens to client-originated IPv6 traffic sent 574 to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547, 575 the LDRA SHOULD implement some form of rate-limiting on received 576 messages to prevent excessive process utilisation. As DHCP is 577 session-oriented, messages in excess of the rate-limit may be 578 silently discarded. 580 The hop count based determination of the trustworthiness of the LDRA 581 can be easily defeated by a rogue relay agent on the network-facing 582 interface of the LDRA. 584 11. References 586 11.1. Normative References 588 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 589 Requirement Levels", RFC 2119, March 1997. 591 [RFC3315] Droms, R., "Dynamic Host Configuration Protocol for IPv6 592 (DHCPv6)", RFC 3315, July 2003. 594 11.2. Informative References 596 [L2RA] Joshi, B., "Layer 2 Relay Agent Information", IETF 597 Draft draft-ietf-dhc-l2ra-04, April 2009. 599 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 600 RFC 3046, January 2001. 602 [TR-101] The Broadband Forum, "Migration to Ethernet-Based DSL 603 Aggregation", Technical Report TR-101, April 2006. 605 Authors' Addresses 607 David Miles (editor) 608 Alcatel-Lucent 609 L3 / 215 Spring St 610 Melbourne, Victoria 3000 611 Australia 613 Phone: +61 3 9664 3308 614 Email: david.miles@alcatel-lucent.com 616 Sven Ooghe 617 Alcatel-Lucent 618 Copernicuslaan 50 619 2018 Antwerp, 620 Belgium 622 Phone: 623 Email: sven.ooghe@alcatel-lucent.com 625 Wojciech Dec 626 Cisco Systems 627 Haarlerberdweg 13-19 628 1101 CH Amsterdam, 629 The Netherlands 631 Phone: 632 Email: wdec@cisco.com 634 Suresh Krishnan 635 Ericsson 636 8400 Blvd Decarie 637 Town of Mount Royal, Quebec 638 Canada 640 Email: suresh.krishnan@ericsson.com 641 Alan Kavanagh] 642 Ericsson 643 8400 Blvd Decarie 644 Town of Mount Royal, Quebec 645 Canada 647 Email: alan.kavanagh@ericsson.com