RFC 5945
Resource Reservation Protocol (RSVP) Proxy Approaches
Pages: 50
Informational
Informational
Part 3 of 3 – Pages 34 to 50
5. Security Considerations
In the environments of concern for this document, RSVP messages are used to control resource reservations on a segment of the end-to-end path of flows. The general security considerations associated with [RFC2205] apply. To ensure the integrity of the associated reservation and admission control mechanisms, the RSVP cryptographic authentication mechanisms defined in [RFC2747] and [RFC3097] can be used. Those protect RSVP messages integrity hop-by-hop and provide node authentication, thereby protecting against corruption, spoofing of RSVP messages, and replay. [RSVP-SEC-KEY] discusses key types and key provisioning methods, as well as their respective applicability to RSVP authentication. [RSVP-SEC-KEY] also discusses applicability of IPsec mechanisms ([RFC4302][RFC4303]) and associated key provisioning methods for security protection of RSVP. This discussion applies to the protection of RSVP in the presence of RSVP proxies as defined in this document. A subset of RSVP messages are signaled with the IP router alert option ([RFC2113], [RFC2711]). Based on the current security concerns associated with the use of the IP router alert option, the applicability of RSVP (and therefore of the RSVP proxy approaches discussed in this document) is limited to controlled environments (i.e., environments where the security risks associated with the use of the IP router alert option are understood and protected against). The security aspects and common practices around the use of the current IP router alert option, and consequences of using the IP router alert option by applications such as RSVP, are discussed in detail in [RTR-ALERT].
A number of additional security considerations apply to the use of RSVP proxies and are discussed below. With some RSVP proxy approaches, the RSVP proxy operates autonomously inside an RSVP router. This is the case for the Path-Triggered Proxy approaches defined in Section 4.1 and in Section 4.2, for the Inspection-Triggered Proxy approach defined in Section 4.3, for the STUN-Triggered Proxy approach defined in Section 4.4, and for the RSVP-Signaling-Triggered approach defined in Section 4.7. Proper reservation operation assumes that the RSVP proxy can be trusted to behave correctly in order to control the RSVP reservation as required and expected by the end-systems. Since the basic RSVP operation already assumes a trust model where end-systems trust RSVP nodes to appropriately perform RSVP reservations, the use of an RSVP proxy that behaves autonomously within an RSVP router is not seen as introducing any significant additional security threat or as fundamentally modifying the RSVP trust model. With some RSVP proxy approaches, the RSVP proxy operates under the control of another entity. This is the case for the Application_Entity-Controlled Proxy approach defined in Section 4.5 and for the Policy_Server-Controlled Proxy approach defined in Section 4.6. This introduces additional security risks since the entity controlling the RSVP proxy needs to be trusted for proper reservation operation and also introduces additional authentication and confidentiality requirements. The exact mechanisms to establish such trust, authentication, and confidentiality are beyond the scope of this document, but they may include security mechanisms inside the protocol used as the control interface between the RSVP proxy and the entity controlling it, as well as security mechanisms for all the interfaces involved in the reservation control chain (e.g., inside the application signaling protocol between the end-systems and the application entity, and, in the case of the Policy_Server-Controlled Proxy approach, in the protocol between the application entity and the policy server). In some situations, the use of RSVP proxy to control reservations on behalf of end-systems may actually reduce the security risk (at least from the network operator viewpoint). This could be the case, for example, because the routers where the RSVP proxy functionality runs are less exposed to tampering than end-systems. Such a case is further discussed in Section 4 of [RFC5946]. This could also be the case because the use of RSVP proxy allows localization of RSVP operation within the boundaries of a given administrative domain (thus easily operating as a controlled environment) while the end-to- end flow path spans multiple administrative domains.
6. Acknowledgments
This document benefited from earlier work on the concept of RSVP proxy including the one documented by Silvano Gai, Dinesh Dutt, Nitsan Elfassy, and Yoram Bernet. It also benefited from discussions with Pratik Bose, Chris Christou, and Michael Davenport. Tullio Loffredo and Massimo Sassi provided the base material for Section 4.6. Thanks to James Polk, Magnus Westerlund, Dan Romascanu, Ross Callon, Cullen Jennings, and Jari Arkko for their thorough review and comments.7. References
7.1. Normative References
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000. [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
7.2. Informative References
[QOS-MOBILE] Manner, J., "Provision of Quality of Service in IP- based Mobile Access Networks", Doctoral dissertation, University of Helsinki, 2003, <http://ethesis.helsinki.fi>. [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999. [RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub Application Identity Policy Element for Use with RSVP", RFC 2872, June 2000. [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001. [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. Moore, "Policy Quality of Service (QoS) Information Model", RFC 3644, November 2003. [RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation Protocol (SIP) Preconditions Framework", RFC 4032, March 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations", RFC 4860, May 2007. [RFC4923] Baker, F. and P. Bose, "Quality of Service (QoS) Signaling in a Nested Virtual Private Network", RFC 4923, August 2007. [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008. [RFC5432] Polk, J., Dhesikan, S., and G. Camarillo, "Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP)", RFC 5432, March 2009.
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, April 2010. [RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and G. Zorn, "Diameter Quality-of-Service Application", RFC 5866, May 2010. [RFC5946] Le Faucheur, F., Manner, J., Narayanan, A., Guillou, A., and H. Malik, "Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy", RFC 5946, October 2010. [RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of- Service Signaling", RFC 5974, October 2010. [RSVP-SEC-KEY] Behringer, M. and F. Le Faucheur, "Applicability of Keying Methods for RSVP Security", Work in Progress, June 2009. [RTR-ALERT] Le Faucheur, F., "IP Router Alert Considerations and Usage", Work in Progress, October 2009. [W3C] "World Wide Web Consortium (W3C) - Web Services Architecture", <http://www.w3.org/TR/ws-arch/>.
Appendix A. Use Cases for RSVP Proxies
A.1. RSVP-Based VoD Admission Control in Broadband Aggregation Networks
As broadband services for residential customers are becoming more and more prevalent, next-generation aggregation networks are being deployed in order to aggregate traffic from broadband users (whether attached via Digital Subscriber Line technology, aka DSL; Fiber To The Home/Curb, aka FTTx; Cable; or other broadband access technology). Video on Demand (VoD) services, which may be offered to broadband users, present significant capacity planning challenges for the aggregation network for a number of reasons. First, each VoD stream requires significant dedicated sustained bandwidth (typically 2-4 Mb/s in Standard Definition TV and 6-12 Mb/s in High Definition TV). Secondly, the VoD codec algorithms are very sensitive to packet loss. Finally, the load resulting from such services is very hard to predict (e.g., it can vary quite suddenly with blockbuster titles made available as well as with promotional offerings). As a result, transport of VoD streams on the aggregation network usually translate into a strong requirement for admission control. The admission control solution protects the quality of established VoD sessions by rejecting the additional excessive session attempts during unpredictable peaks, during link or node failures, or a combination of those factors. RSVP can be used in the aggregation network for admission control of the VoD sessions. However, since customer premises equipment such as Set Top Boxes (STBs) (which behave as the receiver for VoD streams) often do not support RSVP, the last IP hop in the aggregation network can behave as an RSVP Receiver Proxy. This way, RSVP can be used between VoD pumps and the last IP hop in the aggregation network to perform accurate admission control of VoD streams over the resources set aside for VoD in the aggregation network (typically a certain percentage of the bandwidth of any link). As VoD streams are unidirectional, a simple Path-Triggered RSVP Receiver Proxy (as described in Section 4.1) is all that is required in this use case. Figure 14 illustrates operation of RSVP-based admission control of VoD sessions in an aggregation network involving RSVP support on the VoD pump (the senders) and the RSVP Receiver proxy on the last IP hop of the aggregation network. All the customer premises equipment remains RSVP-unaware.
|-------------| | VoD SRM | | | ////////| |\\\\\\\\\\\\\\ / |-------------| \ / \ / \ / \ / \ / \ |****| *** *** *** |********| |-----| |---| |VoD |---*r*---*r*---*r*---|RSVP |---|DSLAM|~~~~|STB|--TV |Pump| *** *** *** |Receiver| |-----| |---| |****| |Proxy | |********| <---Aggregation Net-----------> ************************************************> ==============RSVP================> SRM Session Resource Manager *** |---| *r* regular RSVP |STB| Set Top Box *** router |---| ***> VoD media flow ==> segment of flow path protected by RSVP reservation /\ VoD Application-level signaling (e.g., RTSP) Figure 14: VoD Use Case with Receiver Proxy In the case where the VoD pumps are not RSVP-capable, an Application_Entity-Controlled Sender Proxy via the "RSVP over GRE" approach (as described in Section 4.5.1) can also be implemented on the VoD Controller or Session Resource Manager (SRM) devices typically involved in VoD deployments. Figure 15 illustrates operation of RSVP-based admission control of VoD sessions in an aggregation network involving such an Application_Entity-Controlled Source Proxy combined with an RSVP Receiver Proxy on the last IP hop of the aggregation network. All the customer premises equipment, as well as the VoD pumps, remain RSVP-unaware.
|-------------| ////| VoD SRM |\\\\\\\\\\\ / | | \ / | + | \ / | RSVP Sender | \ / |Proxy Control| \ / |-------------| \ / /=/ \ / /=/ \ / /=/ \ / /=/ \ / /=/ \ |----| |******| *** *** |********| |-----| |---| | VoD|--|RSVP |----*r*--*r*--|RSVP |--|DSLAM|~~~~|STB|--TV |Pump| |Sender| *** *** |Receiver| |-----| |---| |----| |Proxy | |Proxy | |******| |********| <---Aggregation Net-------------> ************************************************> =========RSVP==============> SRM Systems Resource Manager *** |---| *r* regular RSVP |STB| Set Top Box *** router |---| ***> VoD media flow ==> segment of flow path protected by RSVP reservation / VoD Application-level signaling (e.g., RTSP) /=/ GRE-tunneled RSVP (Path messages) Figure 15: VoD Use Case with Receiver Proxy and SRM-Based Sender Proxy The RSVP proxy entities specified in this document play a significant role here since they allow immediate deployment of an RSVP-based admission control solution for VoD without requiring any upgrade to the huge installed base of non-RSVP-capable customer premises equipment. In one mode described above, they also avoid upgrade of non-RSVP-capable VoD pumps. In turn, this means that the benefits of
on-path admission control can be offered to VoD services over broadband aggregation networks without network or VoD pump upgrade. Those include accurate bandwidth accounting regardless of topology (hub-and-spoke, ring, mesh, star, arbitrary combinations) and dynamic adjustment to any change in topology (such as failure, routing change, additional links, etc.).A.2. RSVP-Based Voice/Video Connection Admission Control (CAC) in Enterprise WAN
More and more enterprises are migrating their telephony and videoconferencing applications onto IP. When doing so, there is a need for retaining admission control capabilities of existing TDM- based (Time-Division Multiplexing) systems to ensure the QoS of these applications is maintained even when transiting through the enterprise's Wide Area Network (WAN). Since many of the endpoints already deployed (such as IP phones or videoconferencing terminals) are not RSVP-capable, RSVP proxy approaches are very useful: they allow deployment of an RSVP-based admission control solution over the WAN without requiring upgrade of the existing terminals. A common deployment architecture for such environments relies on the Application_Entity-Controlled Proxy approach as defined in Section 4.5. Routers sitting at the edges of the WAN are naturally "on-path" for all inter-campus calls (or sessions) and behave as RSVP proxies. The RSVP proxies establish, maintain, and tear down RSVP reservations over the WAN segment for the calls (or sessions) under the control of the SIP server/proxy. The SIP server/proxy synchronizes the RSVP reservation status with the status of end-to- end calls. For example, the called IP phone will only be instructed to play a ring tone if the RSVP reservation over the corresponding WAN segment has been successfully established. This architecture allowing RSVP-based admission control of voice and video on the enterprise WAN is illustrated in Figure 16.
|---------| //////////////| SIP |\\\\\\\\\\\\ / | Server/ | \ / | Proxy | \ / |---------| \ / // \\ \ / // \\ \ / // \\ \ / // \\ \ / // \\ \ |-----| |********| *** *** |********| |-----| | IP |------| Media |---*r*---*r*---| Media |-------|IP | |Phone| | Relay | *** *** | Relay | |Phone| |-----| | + | | + | |-----| | RSVP | | RSVP | | Proxy | | Proxy | |********| |********| <--campus--> <--campus--> network network <---------WAN-----------> <*************> <***********************> <**************> <=========RSVP===========> *** *r* Regular RSVP router *** <***> media flow <==> segment of flow path protected by RSVP reservation /\ SIP signaling // control interface between the SIP server/proxy and RSVP proxy Figure 16: CAC on Enterprise WAN Use CaseA.3. RSVP Proxies for Mobile Access Networks
Mobile access networks are increasingly based on IP technology. This implies that, on the network layer, all traffic, both traditional data and streamed data like audio or video, is transmitted as
packets. Increasingly popular multimedia applications would benefit from better than best-effort service from the network, a forwarding service with strict Quality of Service (QoS) with guaranteed minimum bandwidth and bounded delay. Other applications, such as electronic commerce, network control and management, and remote-login applications, would also benefit from a differentiated treatment. The IETF has two main models for providing differentiated treatment of packets in routers. The Integrated Services (IntServ) model [RFC1633], together with the Resource Reservation Protocol (RSVP) [RFC2205], [RFC2210], [RFC2961] provides per-flow guaranteed end-to- end transmission service. The Differentiated Services (Diffserv) framework [RFC2475] provides non-signaled flow differentiation that usually provides, but does not guarantee, proper transmission service. However, these architectures have potential weaknesses for deployment in Mobile Access Networks. For example, RSVP requires support from both communication endpoints, and the protocol may have potential performance issues in mobile environments. Diffserv can only provide statistical guarantees and is not well suited for dynamic environments. Let us consider a scenario, where a fixed network correspondent node (CN) would be sending a multimedia stream to an end host behind a wireless link. If the correspondent node does not support RSVP, it cannot signal its traffic characteristics to the network and request specific forwarding services. Likewise, if the correspondent node is not able to mark its traffic with a proper Differentiated Services codepoint (DSCP) to trigger service differentiation, the multimedia stream will get only best-effort service, which may result in poor visual and audio quality in the receiving application. Even if the connecting wired network is over-provisioned, an end host would still benefit from local resource reservations, especially in wireless access networks, where the bottleneck resource is most probably the wireless link. RSVP proxies would be a very beneficial solution to this problem. It would allow distinguishing local network reservations from the end- to-end reservations. The end host does not need to know the access network topology or the nodes that will reserve the local resources. The access network would do resource reservations for both incoming and outgoing flows based on certain criteria, e.g., filters based on application protocols. Another option is that the mobile end host makes an explicit reservation that identifies the intention, and the access network will find the correct local access network node(s) to respond to the reservation. RSVP proxies would, thus, allow resource reservation over the segment that is the most likely bottleneck, the
wireless link. If the wireless access network uses a local mobility management mechanism, where the IP address of the mobile node does not change during handover, RSVP reservations would follow the mobile node movement.A.4. RSVP Proxies for Reservations in the Presence of IPsec Gateways
[RFC4923] discusses how resource reservation can be supported end-to- end in a nested VPN environment. At each VPN level, VPN routers behave as [RFC4301] security gateways between a plaintext domain and a ciphertext domain. To achieve end-to-end resource reservation, the VPN routers process RSVP signaling on the plaintext side, perform aggregation of plaintext reservations, and maintain the corresponding aggregate RSVP reservations on the ciphertext side. Each aggregate reservation is established on behalf of multiple encrypted end-to-end sessions sharing the same ingress and egress VPN routers. These aggregate reservations can be as specified in [RFC3175] or [RFC4860]. Section 3 of [RFC4923] discusses the necessary data flows within a VPN router to achieve the behavior described in the previous paragraph. Two mechanisms are described to achieve such data flows. Section 3.1 presents the case where the VPN router carries data across the cryptographic boundary. Section 3.2 discusses the case where the VPN router uses a Network Guard. Where such mechanisms are not supported by the VPN routers, the approach for end-to-end reservations presented in [RFC4923] cannot be deployed. An alternative approach to support resource reservations within the ciphertext core is to use the Application_Entity- Controlled Proxy approach (as defined in Section 4.5) in the following way: o the RSVP proxies are located inside the ciphertext domain and use aggregate RSVP reservations. o the application entity exchange application-level signaling with the end-systems in the plaintext domain. o the application entity controls the RSVP proxies in the ciphertext domain via an RSVP proxy control interface. This is illustrated in Figure 17 in the case where the application is SIP-based multimedia communications.
|-------| |-------| |SIP |///////////////////\\\\\\\\\\\\\\\\\|SIP | /|Server/| |Server/|\ / |Proxy | |Proxy | \ / |-------| |-------| \ / ^ \\ // ^ \ / ^ \\ // ^ \ / ^ \\ // ^ \ |***| |------| |********| *** *** |********| |------| |***| | S |---|IPsec |--| ARSVP |---*r*---*r*---| ARSVP |--|IPsec |---| R | |***| | GW | | Sender | *** *** |Receiver| | GW | |***| |------| | Proxy | | Proxy | |------| |********| |********| ***PT*****> **********************CT****************> ****PT***> =====> =====> =====ARSVP======> |****| RSVP-capable |****| RSVP-capable *** | S | Sender | R | Receiver *r* regular RSVP |****| |****| *** router |------| |IPsec | IPsec security gateway | GW | |------| ARSVP Aggregate RSVP ***> media flow ==> segment of flow path protected by RSVP reservation / \ SIP signaling ^ Network management interface between SIP server/proxy and IPsec security gateway // control interface between SIP server/proxy and ARSVP proxy PT Plaintext network CT Ciphertext network Figure 17: RSVP Proxies for Reservations in the Presence of IPsec Gateways
Where the sender and receiver are RSVP-capable, they may also use RSVP signaling. This achieves resource reservation on the plaintext segments of the end-to-end, i.e., o from the sender to the ingress IPsec gateway, and o from the egress IPsec gateway to the receiver. In this use case, because the VPN routers do not support any RSVP- specific mechanism, the end-to-end RSVP signaling is effectively hidden by the IPsec gateways on the ciphertext segment of the end-to- end path. As with the Application_Entity-Controlled Proxy approach (defined in Section 4.5), the solution here for synchronizing RSVP signaling with application-level signaling is to rely on an application-level signaling device that controls an on-path RSVP proxy function. However, in this use case, the RSVP proxies are a component of a ciphertext network where all user (bearer) traffic is IPsec encrypted. This has a number of implications, including the following: 1. encrypted flows cannot be identified in the ciphertext domain so that network nodes can only classify traffic based on IP address and Differentiated Services codepoints (DSCPs). As a result, only aggregate RSVP reservations (such as those specified in [RFC3175] or [RFC4860]) can be used. This is similar to [RFC4923]. 2. Determining the RSVP Sender Proxy and RSVP Receiver Proxy to be used for aggregation of a given flow from sender to receiver creates a number of challenges. Details on how this may be achieved are beyond the scope of this document. We observe that, as illustrated in Figure 17, this may be facilitated by a network management interface between the application entity and the IPsec gateways. For example, this interface may be used by the application entity to obtain information about which IPsec gateway is on the path of a given end-to-end flow. Then, the application entity may maintain awareness of which RSVP proxy is on the ciphertext path between a given pair of IPsec gateways. How such awareness is achieved is beyond the scope of this document. We simply observe that such awareness can be easily achieved through simple configuration in the particular case where a single (physical or logical) RSVP proxy is fronting a given IPsec gateway. We also observe that when awareness of the RSVP Receiver Proxy for a particular egress IPsec gateway (or
end-to-end flow) is not available, the aggregate reservation may
be signaled by the RSVP Sender Proxy to the destination address
of the egress IPsec gateway and then proxied by the RSVP Receiver
Proxy.
Different flavors of operations are possible in terms of aggregate
reservation sizing. For example, the application entity can initiate
an aggregate reservation of fixed size a priori and then simply keep
count of the bandwidth used by sessions and reject sessions that
would result in excess usage of an aggregate reservation. The
application entity could also re-size the aggregate reservations on a
session-by-session basis. Alternatively, the application entity
could re-size the aggregate reservations in step increments typically
corresponding to the bandwidth requirement of multiple sessions.
Authors' Addresses
Francois Le Faucheur Cisco Systems Greenside, 400 Avenue de Roumanille Sophia Antipolis 06410 France Phone: +33 4 97 23 26 19 EMail: flefauch@cisco.com Jukka Manner Aalto University Department of Communications and Networking (Comnet) P.O. Box 13000 FIN-00076 Aalto Finland Phone: +358 9 470 22481 EMail: jukka.manner@tkk.fi URI: http://www.netlab.tkk.fi/~jmanner/ Dan Wing Cisco Systems 170 West Tasman Drive San Jose, CA 95134 United States EMail: dwing@cisco.com Allan Guillou SFR 40-42 Quai du Point du Jour Boulogne-Billancourt 92659 France EMail: allan.guillou@sfr.com