idnits 2.17.1 draft-ietf-dhc-dhcpv6-ldra-00.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 date (July 2, 2009) is 5409 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-06) exists of draft-ietf-dhc-l2ra-02 Summary: 2 errors (**), 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: Informational Alcatel-Lucent 5 Expires: January 3, 2010 W. Dec 6 Cisco Systems 7 S. Krishnan 8 A. Kavanagh 9 Ericsson 10 July 2, 2009 12 Lightweight DHCPv6 Relay Agent (LDRA) 13 draft-ietf-dhc-dhcpv6-ldra-00 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 3, 2010. 38 Copyright Notice 40 Copyright (c) 2009 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 in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that 52 is used to insert relay agent options in DHCPv6 message exchanges 53 identifying client-facing interfaces. The LDRA can be implemented in 54 existing access nodes (such as DSLAMs and Ethernet switches) that do 55 not support IPv6 control or routing functions. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. Relay-Forward Message . . . . . . . . . . . . . . . . . . 5 65 4.2. Relay-Reply Message . . . . . . . . . . . . . . . . . . . 5 66 4.3. Mandatory DHCP Options . . . . . . . . . . . . . . . . . . 5 67 4.3.1. Relay-Message Option . . . . . . . . . . . . . . . . . 5 68 4.3.2. Interface-ID Option . . . . . . . . . . . . . . . . . 6 69 5. Agent Behaviour . . . . . . . . . . . . . . . . . . . . . . . 6 70 5.1. Relaying a Client Message . . . . . . . . . . . . . . . . 6 71 5.1.1. Client Message Validation . . . . . . . . . . . . . . 7 72 5.1.2. Trusted and Untrusted Interfaces . . . . . . . . . . . 7 73 5.2. Relaying a Relay-Reply message from the network . . . . . 8 74 6. Network Topology . . . . . . . . . . . . . . . . . . . . . . . 9 75 6.1. Client and Server on Same Link . . . . . . . . . . . . . . 9 76 6.2. Client and Server behind Relay Agent . . . . . . . . . . . 10 77 6.3. Relay Agent in Front of LDRA . . . . . . . . . . . . . . . 11 78 7. Server Considerations . . . . . . . . . . . . . . . . . . . . 12 79 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 84 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 87 1. Introduction 89 DHCPv6 Relay-Agents [RFC3315] are deployed to forward DHCPv6 messages 90 between clients and servers when they are not on the same IPv6 link 91 and are often implemented alongside a routing function in a common 92 node. A Lightweight DHCPv6 Relay Agent (LDRA) allows Relay Agent 93 Information to be inserted by an access node that performs a link- 94 layer bridging (i.e. non-routing) function. A LDRA resides on the 95 same IPv6 link as the client and a DHCPv6 Relay Agent or Server and 96 is functionally the equivalent of the Layer 2 DHCP Relay draft[L2RA] 97 proposed for DHCPv4 operation. 99 Unlike a DHCPv6 Relay-Agent specified in [RFC3315], a LDRA does not 100 implement any IPv6 control functions (e.g. ICMPv6) or have any 101 routing capability in the node. 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 2. Background 111 A variety of different link-layer network topologies exist for the 112 aggregation of IPv6 nodes into one or more routers. In Layer 2 113 aggregation networks (IEEE 802.1D bridging or similar) that have many 114 nodes on a single link, a DHCPv6 server or DHCP relay agent would 115 normally be unaware of how a DHCP client is attached to the network. 116 The LDRA allows Relay Agent Information, including the Interface-ID 117 option [RFC3315], to be inserted by the access node so that it may be 118 used by the DHCPv6 server for client identification. A typical 119 application in a broadband service provider may be as an equivalent 120 to the Broadband Forum TR-101 Layer 2 DHCP Relay Agent[TR-101] 121 described in [L2RA] 123 3. Terminology 125 Address An IP layer identifier for an interface or 126 set of interfaces 128 Host A non-routing IPv6 node that is 129 participating in DHCPv6 message exchange 131 IP Internet Protocol Version 6 (IPv6) 133 LDRA Lightweight DHCPv6 Relay Agent 135 Link A communication facility or medium over 136 which nodes can communicate at the link 137 layer 139 Link-local address An IP address having only local-scope, 140 indicated by having the address prefix 141 FE80::/10, that can be used to reach 142 neighbouring nodes attached to the same 143 link. Every interface has a link-local 144 address. 146 Node A device that implements IPv6 148 Router A node that forwards packets not directly 149 addressed to itself 151 Access Node A device that combines many interfaces onto 152 one link. An access node is not IP-aware 153 in the data path 155 Relay Agent A node that acts as an intermediary to 156 deliver DHCP messages between clients and 157 servers and being on the same link as the 158 client 160 Lightweight Relay Agent A function on the access node that 161 intercepts DHCP messages between clients 162 and servers. The function exists as a bump 163 in the wire on the IP link. 165 Unspecified address An IP address that is comprised entirely of 166 zeros 168 4. Message Format 170 The Lightweight DHCPv6 Relay Agent (LDRA) exchanges DHCP messages 171 between clients and servers using the message formats established in 172 [RFC3315]. 174 To maintain interoperability with existing DHCP relays and servers 175 the message format is unchanged from [RFC3315]. The LDRA implements 176 the same message types as a normal DHCPv6 Relay Agent. They are: 178 o Relay-Forward Messages 180 o Relay-Reply Messages 182 4.1. Relay-Forward Message 184 The Relay-Forward message is created by any DHCPv6 Relay Agent, 185 including an LDRA, to forward messages between clients and servers or 186 other relay agents. These messages are built as specified in 187 [RFC3315] 189 The Relay-Forward message contains relay agent parameters that 190 identify the client-facing interface on which any reply messages 191 should be forwarded. These parameters are link-address, peer-address 192 and Interface-ID. The link-address parameter MUST be set to the 193 unspecified address. The Interface-ID Relay Agent Option MUST be 194 included in the Relay-Forward message. The LDRA MAY insert 195 additional relay agent options. 197 4.2. Relay-Reply Message 199 The Relay-Reply message is constructed by a DHCPv6 server to send 200 parameters to a DHCP client when a relay agent is present between the 201 server and the client. The Relay-Reply message may be sent after an 202 initial Relay-Forward message as the parameters link-address, peer- 203 address, Interface-ID and the relay agent's IP address are learnt 204 from the Relay-Forward message. 206 The server MUST include the Interface-ID option in the Relay-Reply 207 Message to indicate to the LDRA the interface on which the de- 208 capsulated message should be forwarded. 210 4.3. Mandatory DHCP Options 212 Parameters are exchanged between DHCP client, relay-agent and server 213 through the use of DHCP options. There are a set of mandatory DHCP 214 options that MUST be included by the LDRA in all Relay-Forward and 215 Relay-Reply messages. These are the: 217 o Relay-Message Option 219 o Interface-ID Option 221 4.3.1. Relay-Message Option 223 A DHCPv6 Relay Agent relays messages between clients and servers or 224 other relay agents through Relay-Forward and Relay-Reply message 225 types. The original client DHCP message (i.e. the packet payload, 226 excluding UDP and IP headers) is encapsulated in a Relay Message 227 option [RFC3315]. 229 As an LDRA does not implement ICMPv6, fragmentation of Relay-Messages 230 is not supported. If a Relay-Message would exceed the MTU of the 231 outgoing interface it MUST be discarded and an error condition SHOULD 232 be logged. 234 4.3.2. Interface-ID Option 236 The LDRA MUST include the Interface-ID option [RFC3315] in all Relay- 237 Forward messages. When a LDRA receives a Relay-reply message with an 238 Interface-ID option present and link-address unspecified, the LDRA 239 MUST relay the decapsulated message to the client on the interface 240 identified in the Interface-ID option. 242 Servers MAY use the Interface-ID for parameter assignment policies. 243 The format of the Interface-ID is outside the scope of this 244 contribution. The Interface-ID SHOULD be considered an opaque value, 245 i.e. the server SHOULD NOT try to parse the contents of the 246 Interface-ID option. The LDRA SHOULD use the same Interface-ID value 247 for a given interface, and this value SHOULD be retained across 248 restarts. This is because, if the Interface-ID changes, a server 249 will not be able to use it reliably in parameter assignment policies. 251 5. Agent Behaviour 253 The LDRA MUST have each of its interfaces configured as either 254 client-facing or network (DHCPv6 server) facing. The LDRA uses the 255 notion of client-facing and network-facing interfaces to process the 256 DHCPv6 messages. 258 5.1. Relaying a Client Message 260 When a DHCPv6 message (defined in [RFC3315]) is received on any 261 client-facing interface, the LDRA MUST intercept and process the 262 message. The LDRA MUST also prevent the original message from being 263 forwarded on the network facing interface. 265 The lightweight relay agent adds any other options it is configured 266 or required to include in the Relay-Forward message. The LDRA MUST 267 set the link-address field of the Relay-forward message to the 268 Unspecified Address (::) and MUST include the Interface-ID option in 269 all DHCP Relay-Forward messages. 271 If the message received on the client-facing interface is a Relay- 272 Forward message, the LDRA MUST set the Hop-Count field in the newly 273 created Relay-Forward message to the value of the hop-count field in 274 the received message incremented by 1 as specified in [RFC3315]. 276 The LDRA MUST copy the IP destination and link-layer destination 277 addresses from the client-originated message into the IP destination 278 address and link-layer destination address of the Relay-forward 279 message. 281 The LDRA MUST copy the IP source address from the client-originated 282 message into the peer-address field of the Relay-forward message. 283 The LDRA MUST copy the link-layer source address from the client- 284 originated message into the link-layer source address of the Relay- 285 forward message. 287 5.1.1. Client Message Validation 289 On receipt of a DHCP message on the client facing interface, the LDRA 290 MUST discard a message if it is of one of following message types: 292 o ADVERTISE (2) 294 o REPLY (7) 296 o RECONFIGURE (10) 298 o RELAY-REPLY (13) 300 Options contained in the DHCPv6 message MUST NOT be validated by the 301 LDRA, making it the responsibility of the DHCP server to check 302 message option validity and allow new options to be introduced 303 without changes on the LDRA. 305 5.1.2. Trusted and Untrusted Interfaces 307 In [RFC3046] DHCPv4 relay-agents had their client-facing interfaces 308 set to trusted and untrusted. An LDRA MUST implement a trusted/ 309 untrusted definition for all client-facing interfaces that SHOULD be 310 configurable per interface. When a client-facing interface is deemed 311 untrusted the LDRA MUST discard any message received from the client- 312 facing interface of type RELAY-FORWARD (12). 314 In DHCPv4 it was not possible for a DHCP server to determine whether 315 the client or an intermediate relay agent had added relay agent 316 options and thus trusted interfaces (relay-agent interfaces that 317 would allow any DHCP options to be present on incoming messages) and 318 untrusted interfaces (relay-agent interfaces that would ensure there 319 are no relay-agent options on incoming messages) were defined. In 320 DHCPv6, relay agents encapsulate the received message into the Relay- 321 Message Option in addition to adding any relay-agent options. This 322 nested message behaviour allows a server to identify the options each 323 relay-agent has inserted along the path, whenever the data path 324 between LDRA and server falls within a protected or operator 325 controlled environment. 327 When an LDRA is deployed, DHCPv6 servers MAY be configured with the 328 Relay-Forward hop-count of the LDRA to instruct at which level of 329 nesting the relay-agent options should be parsed. This removes the 330 need for an interface to be configured as trusted or untrusted by 331 providing the DHCPv6 server with an awareness of the LDRA logical 332 location in the DHCP relay path. This behaviour is dependent on the 333 interception of all DHCP messages by the LDRA and the incrementing of 334 the Relay-Forward hop-count if a Relay-Forward message is received 335 from the client-facing LDRA interface. 337 5.2. Relaying a Relay-Reply message from the network 339 When a valid Relay-Reply is received on any network-facing access 340 node interface, it MUST be intercepted by the LDRA. The LDRA MUST 341 listen to all IP traffic that has a link-local scoped source address, 342 link-local scoped destination address, protocol type UDP and 343 destination port 547. The LDRA SHOULD ignore any message that does 344 not meet this criteria and MUST allow it to be forwarded like any 345 other packet. The LDRA MAY be configured to listen only to a 346 specific destination address if it has been configured as a node 347 (implementing a full IP stack). 349 The LDRA MUST intercept and process all DHCP Relay-Reply messages and 350 MUST silently discard all other DHCP message types. 352 In addition to the validity checks performed by a relay agent in 353 [RFC3315] , the Relay-Reply message is considered valid by the LDRA 354 if: 356 - The Interface-ID Option is present and the value corresponds to a 357 valid interface in the access node, 359 - the Relay-Reply peer-address and the destination IP address MUST be 360 identical and MUST be a link-local scoped address when no IP address 361 is configured on the LDRA, and 363 - the link-address is the Unspecified Address when no IP address is 364 configured on the LDRA 366 The LDRA copies the peer-address into the destination IP address 367 field, and MAY use the destination link-layer address (MAC address) 368 or Interface-ID to determine which interface to send the message to 369 the client. The contents of the Relay Message Option is put into an 370 IP/UDP packet and then forwarded to the client. 372 The LDRA MUST copy the link-layer and IP source address from the 373 Relay-Reply message into the IP/UDP packet that is forwarded to the 374 client. 376 6. Network Topology 378 The LDRA intercepts any DHCPv6 message received on client-facing 379 interfaces with a destination IP address of 380 All_DHCP_Relay_Agents_and_Servers (FF02::1:2). The LDRA MUST NOT 381 forward the original client message to a network-facing interface, it 382 MUST process the message and add the appropriate Relay-Forward 383 options as described in previous sections. 385 6.1. Client and Server on Same Link 387 The access node acts as a bridge; it has no information about any IP 388 prefixes that are valid on the link, thus a server should consider 389 address and parameter assignment as if the client DHCP message was 390 not relayed. 391 +--------+ 392 Client -------| | 393 | Access | 394 Client -------| Node |-----+ 395 | (LDRA) | | 396 Client -------| | | 397 +--------+ | 398 | +--------+ 399 |------| Server | 400 | +--------+ 401 +--------+ | 402 Client -------| | | 403 | Access | | 404 Client -------| Node |-----+ 405 | (LDRA) | 406 Client -------| | 407 +--------+ 409 <------IPv6 Link-----> 411 For example, if a client sent a DHCP solicit message that was relayed 412 by the LDRA and then to the server, the server would receive the 413 following Relay-Forward message from the LDRA: 415 src-ip: client link-local address 416 dst-ip: All_DHCP_Relay_Agents_and_Servers 417 msg-type: RELAY-FORWARD 418 hop-count: 0 419 link-address: Unspecified_Address 420 peer-address: client link-local address 421 Interface-ID Option: 422 interface-id: LDRA-inserted interface-id 423 Relay-Message Option, which contains: 424 msg-type: SOLICIT 425 Solicit Message Options: 427 6.2. Client and Server behind Relay Agent 429 The client and server are on different IPv6 links, separated by one 430 or more relay agents that will typically act as a router. The LDRA 431 will send Relay-Forward messages upstream towards the second relay 432 agent which in turn will process the messages. 433 +--------+ 434 Client -------| | 435 | Access | 436 Client -------| Node |-----+ 437 | (LDRA) | | 438 Client -------| | | 439 +--------+ | 440 | +--------+ +--------+ 441 |------| RelayB |---------| Server | 442 | +--------+ +--------+ 443 +--------+ | 444 Client -------| | | 445 | Access | | 446 Client -------| Node |-----+ 447 | (LDRA) | 448 Client -------| | 449 +--------+ 451 <--IPv6 Link A--> <--IPv6 Link B--> 453 For example, if a client sent a DHCP solicit message that was relayed 454 by the LDRA to another relay agent and then to the server, the server 455 would receive the following Relay-Forward message from the LDRA: 457 src-ip: relayB 458 dst-ip: server 459 msg-type: RELAY-FORWARD 460 hop-count: 1 461 link-address: relayB address from link A 462 peer-address: client link-local address 463 Relay-Message Option, which contains: 464 msg-type: RELAY-FORWARD 465 hop-count: 0 466 link-address: Unspecified_Address 467 peer-address: client link-local address 468 Interface-ID Option: 469 interface-id: LDRA-inserted interface-id 470 Relay-Message Option, which contains: 471 msg-type: SOLICIT 472 Solicit Message Options: 474 6.3. Relay Agent in Front of LDRA 476 The client and server are on different IPv6 links, separated by one 477 or more relay agents that will typically act as a router and there is 478 an [RFC3315] Relay Agent on the client-facing Interface of the LDRA. 479 The LDRA will send Relay-Forward messages upstream towards the second 480 relay agent which in turn will process the messages. 481 +--------+ 482 RelayC -------| | 483 | Access | 484 RelayC -------| Node |-----+ 485 | (LDRA) | | 486 RelayC -------| | | 487 +--------+ | 488 | +--------+ +--------+ 489 |------| RelayB |---------| Server | 490 | +--------+ +--------+ 491 +--------+ | 492 RelayC -------| | | 493 | Access | | 494 RelayC -------| Node |-----+ 495 | (LDRA) | 496 RelayC -------| | 497 +--------+ 499 <--IPv6 Link A--> <--IPv6 Link B--> 501 For example, if a client sent a DHCP solicit message that was relayed 502 by the LDRA to another relay agent and then to the server, the server 503 would receive the following Relay-Forward message from the LDRA: 505 src-ip: relayB 506 dst-ip: server 507 msg-type: RELAY-FORWARD 508 hop-count: 2 509 link-address: relayB address from link A 510 peer-address: relayC 511 Relay-Message Option, which contains: 512 msg-type: RELAY-FORWARD 513 hop-count: 1 514 link-address: Unspecified_Address 515 peer-address: relayC 516 Interface-ID Option: 517 interface-id: LDRA-inserted interface-id 518 Relay-Message Option, which contains: 519 msg-type: RELAY-FORWARD 520 hop-count: 0 521 link-address: global or unspecified address 522 peer-address: end client address 523 Interface-ID Option: (if required) 524 interface-id: relayC inserted Interface-ID 525 Relay-Message Option, which contains: 526 msg-type: SOLICIT 527 Solicit Message Options: 529 7. Server Considerations 531 Although permitted in [RFC3315] the LDRA makes specific use of Relay- 532 Forward link-address fields with a zero value. 534 o A DHCPv6 server MUST ignore any Relay-Forward link-addresses field 535 with a zero value in Relay-Forward messages when searching for the 536 inner-most link-address field. This allows the DHCPv6 server to 537 select an address appropriate to the L3 link and supports a 538 combination of L3 DHCPv6 relay agents and LDRA. 540 o If no non-zero Relay-Forward link-address is found, the DHCPv6 541 server should act as though the message were directly received. 542 This is the case where no LDRA is present. 544 8. Contributors 546 The authors would like to thank the following for their support, 547 Lieven Levrau, Alastair Johnson, Robert Haylock, Mickey Vucic, Ludwig 548 Pauwels, Fernando Cuervo, John Kaippallimalil, Fredrik Garneij and 549 Alfred Hoenes. 551 Comments are solicited and should be addressed to the DHC WG mailing 552 list (dhcwg@ietf.org) and/or the author. 554 9. IANA Considerations 556 This document does not introduce any new namespaces for the IANA to 557 manage. 559 10. Security Considerations 561 Although the LDRA only listens to client-originated IPv6 traffic sent 562 to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547, 563 the LDRA SHOULD implement some form of rate-limiting on received 564 messages to prevent excessive process utilisation. As DHCP is 565 session-oriented, messages in excess of the rate-limit may be 566 silently discarded. 568 The hop count based determination of the trustworthiness of the LDRA 569 can be easily defeated by a rogue relay agent on the network-facing 570 interface of the LDRA. 572 11. References 574 11.1. Normative References 576 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 577 Requirement Levels", RFC 2119, March 1997. 579 [RFC3315] Droms, R., "Dynamic Host Configuration Protocol for IPv6 580 (DHCPv6)", RFC 3315, July 2003. 582 11.2. Informative References 584 [L2RA] Joshi, B., "Layer 2 Relay Agent Information", IETF 585 Draft draft-ietf-dhc-l2ra-02, May 2008. 587 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 588 RFC 3046, January 2001. 590 [TR-101] The Broadband Forum, "Migration to Ethernet-Based DSL 591 Aggregation", Technical Report TR-101, April 2006. 593 Authors' Addresses 595 David Miles (editor) 596 Alcatel-Lucent 597 L3 / 215 Spring St 598 Melbourne, Victoria 3000 599 Australia 601 Phone: +61 3 9664 3308 602 Email: david.miles@alcatel-lucent.com 604 Sven Ooghe 605 Alcatel-Lucent 606 Copernicuslaan 50 607 2018 Antwerp, 608 Belgium 610 Phone: 611 Email: sven.ooghe@alcatel-lucent.com 613 Wojciech Dec 614 Cisco Systems 615 Haarlerberdweg 13-19 616 1101 CH Amsterdam, 617 The Netherlands 619 Phone: 620 Email: wdec@cisco.com 622 Suresh Krishnan 623 Ericsson 624 8400 Blvd Decarie 625 Town of Mount Royal, Quebec 626 Canada 628 Email: suresh.krishnan@ericsson.com 629 Alan Kavanagh] 630 Ericsson 631 8400 Blvd Decarie 632 Town of Mount Royal, Quebec 633 Canada 635 Email: alan.kavanagh@ericsson.com