Network Working Group J.L. Le Roux (France Telecom) Internet Draft D. Brungard (AT&T) Category: Informational E. Oki (NTT) Expires:
JanuaryApril 2007 D. Papadimitriou (Alcatel) K. Shiomoto (NTT) M. Vigoureux (Alcatel) October 2006 Evaluation of existing GMPLS Protocols against Multi Layer and Multi Region Networks (MLN/MRN) draft-ietf-ccamp-gmpls-mln-eval-01.txtdraft-ietf-ccamp-gmpls-mln-eval-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document provides an evaluation of Generalized Multi-Protocol Label Switching (GMPLS) protocols and mechanisms against the requirements for Multi-Layer Networks (MLN) and Multi-Region Networks (MRN). In addition, this document identifies areas where additional protocol extensions or procedures are needed to satisfy these requirements, and provides guidelines for potential extensions. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Table of Contents 1. Terminology.................................................3 2. Introduction................................................3 3. MLN/MRN Requirements Overview...............................4 4. Analysis....................................................5Analysis....................................................4 4.1. Multi-Layer Aspects.........................................5Aspects.........................................4 4.1.1. Support for Virtual Network Topology Reconfiguration........5Reconfiguration........4 22.214.171.124. Control of FA-LSPs Setup/Release..........................5 126.96.36.199. Virtual TE-Links..........................................7TE-Links..........................................6 188.8.131.52. Traffic Disruption Minimization During FA Release.........8 184.108.40.206. Stability.................................................8 4.1.2. Support for FA-LSP Attributes Inheritance...................8 4.1.3. Support for Triggered Signaling.............................9Signaling.............................8 4.1.4. FA Connectivity Verification................................9 4.2. Multi-Region Specific Aspects...............................9 4.2.1. Support for Multi-Region Signaling..........................9 4.2.2. Advertisement of Internal Adaptation Capabilities..........10 4.3. Client and server network aspects..........................12 4.3.1. Administrative boundary....................................12 4.3.2. Path computation across separated TEDs.....................12 4.3.3. Association between TE-links in separated TEDs.............125. Evaluation Conclusion......................................12 6. Security Considerations....................................13 7. Acknowledgments............................................13 8. References.................................................13 8.1. Normative..................................................13 8.2. Informative................................................14Informative................................................13 9. Authors' Addresses:........................................14 10. Intellectual Property Statement............................15 1. Terminology This document uses terminologies defined in [RFC3945], [HIER],[RFC4206], and [MLN-REQ]. 2. Introduction Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to handle multiple switching technologies: packet switching (PSC), layer-two switching (L2SC), TDM switching (TDM), wavelength switching (LSC) and fiber switching (FSC) (see [RFC 3945]). A data plane layer is a collection of network resources capable of terminating and/or switching data traffic of a particular format. For example, LSC, TDM VC-11 and TDM VC-4-64c represent three different layers. A network comprising transport nodes with different data plane switching layers controlled eitherby a single GMPLS control plane instance is called a Multi-Layer Network (MLN). A GMPLS switching type (PSC, TDM, etc.) describes the ability of a node to forward data of a particular data plane technology, and uniquely identifies a control plane region. The notion of LSP Region is defined in [HIER].[RFC4206]. A network comprised of multiple switching types (e.g. PSC and TDM) controlled by a single GMPLS control plane instance is called a Multi-Region Network (MRN). Note that the region is a control plane only concept. That is, layers of the same region share the same switching technology and, therefore, need the same set of technology specific signaling objects. Note that a MRN is necessarily a MLN, but not vice versa, as a MLN may consist of a single region (control of multiple data plane layers within a region). Hence, in the following, we use the term layer if the mechanism discussed applies equally to layers and regions (e.g. VNT, virtual TE-link, etc.), and we specifically use the term region if the mechanism applies only for supporting a MRN. A customer network may be provided on top of a server GMPLS-based MRN/MLN which is operated by a service provider. For example, a pure IP and/or an IP/MPLS network can be provided on top of GMPLS-based packet over optical networks [IW-MIG-FW]. The relationship between the networks is a client/server relationship and such services are referred to as "MRN/MLN services". In this case, the customer network may form part of the MRN/MLN, or may be partially separated, for example to maintain separate routing information but retain common signalling.The objectives of this document are to evaluate existing GMPLS mechanisms and protocols ([RFC 3945], [GMPLS-RTG], [GMPLS-SIG])[RFC4202], [RFC3471]) against the requirements for MLN and MRN, defined in [MLN-REQ]. From this evaluation, we identify several areas where additional protocol extensions and modifications are required to meet these requirements, and provide guidelines for potential extensions. Section 3 provides anAn overview of MLN/MRN requirements. Sectionrequirements is provided in section 3. Then section 4 evaluates for each of these requirements, whether current GMPLS protocols and mechanisms allow addressing the requirements. When the requirements are not met, the document identifies whether the required mechanisms could rely on GMPLS protocols and procedure extensions or if it is entirely out of the scope of GMPLS protocols. Note that this document specifically addresses GMPLS control plane functionality for MLN/MRN in the context of a single administrative control plane partition. 3. MLN/MRN Requirements Overview [MLN-REQ] lists a set of functional requirements for Multi Layer/Region Networks (MLN/MRN). These requirements are summarized below: - Support of robust Virtual Network Topology (VNT) reconfiguration. This implies the following requirements: - Optimal control of FA-LSP setup and release; - Support for virtual TE-links; - Traffic Disruption minimization during FA-LSP release (e.g. network reconfiguration events); - StabilityStability; - Support for FA-LSP attributes inheritance; - Support for Triggered Signaling; - Support for FAFA-LSP data plane connectivity verification; - Support for Multi-regionMulti-Region signaling; - Advertisement of the adaptation capabilities and resources; Interconnection of MLN/MRN (server) networks with administratively separated client networks introduces as set of specific requirements: - Support for administrative boundary between client and server MLN/MRN network , minimizing impact on the customer network design, operation, and administration; - Support for path computation across separated TEDs associated with client and server MLN/MRN network; - Support for association between TE-links in separated TEDs associated with client and server MLN/MRN networks;4. Analysis 4.1. Multi-Layer Aspects 4.1.1. Support for Virtual Network Topology Reconfiguration A set of lower-layer FA-LSPs provides a Virtual Network Topology (VNT) to the upper-layer. By reconfiguring the VNT (FA-LSP setup/release) according to traffic demands between source and destination node pairs of a layer, network performance factors such as maximum link utilization and residual capacity of the network can be optimized. Such optimal VNT reconfiguration implies several mechanisms that are analyzed in the following sections. Note that the VNT approach is just one approach among others, to perform inter-layer Traffic Engineering. 220.127.116.11. Control of FA-LSPs Setup/Release In a Multi-Layer Network, FA-LSPs are created, modified, released periodically according to the change of incoming traffic demands from the upper layer. This implies a TE mechanism that takes into account the demands matrix, the TE topology and potentially the current VNT, in order to compute a new VNT. Several functional building blocks are required to support such TE mechanism: - Discovery of TE topology and available resources;resources. - Collection of traffic demands of the upper layer;layer. - VNT resources policing/scheduling with regards to traffic demands and usage (i.e. decision to setup/release FAs); The functional component in charge of this function is called a VNT Manager (VNTM), it may be distributed on network elements or centralized on an external tool (see [VNTM]). It may also be partially centralized and distributed;distributed. - VNT Path Computation according to TE topology, and potentially taking into account old VNT (to minimize changes); The Functional component in charge of VNT computation may be distributed on network elements or may be centralized on an external tool (such as e.g. a PCE);PCE). - FA-LSP setup/release. GMPLS routing protocols support TE topology discovery anddiscovery. GMPLS signaling protocols allow setting up/releasing FA-LSPs. VNT Management functions (resources policing/scheduling, decision to setup/release FA, FA configuration) are out of the scope of GMPLS protocols. Such functionalities can be achieved directly on layer border LSRs, and/or on one or more external tools. When an external tool is used, an interface is required between the VNTM and network elements so has to setup/releases FA-LSPs. This may rely on SNMP (TE MIB) or on proprietary interfaces. The set of traffic demands of the upper layer is required for the VNT Manager to take decisions to setup/release FAs. This requires knowledge of the aggregated bandwidth reserved by upper layer LSPs established between any pair of border LSRs. Existing GMPLS routing allows for the collection of traffic demands of the upper region. It can be deduced from FA TE-link advertisements. The set of traffic demands can be inferred: - either directly, based on upper-layer FA TE-link advertisements. The traffic demands between two points correspond to the cumulated bandwidth reserved by upper-layer LSPs between these two points; - or indirectly, based on lower-layer FA TE-link advertisements. In this case a mechanism to infer the upper-layer traffic demand from the aggregated bandwidth reserved in lower-layer LSPs might be required, as all pairs of border nodes may not be directly connected by a lower layer LSP. Collection of traffic demands of an upper region may actually be achieved in several ways depending on the location of VNT Managers: - If a VNTM is distributed on border layer LSRs, then the collection of traffic demands would rely on existing GMPLS routing, as per described above; - If a VNTM is centralized on an external tool, then the collection of traffic demands may be achieved using existing GMPLS routing, provided that the tool relies on GMPLS routing to discover TE link information, or it may rely on another mechanism out of the scope of GMPLS protocols (e.g. SNMP TE-link MIB). Finally, VNT computation can be performed directly on layer border LSRs or on an external tool (such as an external PCE) and this independently of the location of the VNTM. VNT computation is triggered by the VNTM (e.g. when the Path computation is externalized on a PCE, the VNTM acts as PCC). Hence no GMPLS protocol extensions are required to control FA-LSP setup/release. 18.104.22.168. Virtual TE-Links A Virtual TE-link is a TE-link between two nodes, not actually associated to a fully provisioned FA-LSP. A Virtual TE-link represents the potentiality to setup a FA-LSP. There is no IGP adjacency associated to a Virtual TE-link. A Virtual TE-link is advertised as any classical TE-link, i.e. following the rules in [HIER][RFC4206] defined for fully provisioned TE-links. Particularly, the flooding scope of a Virtual TE-link is within an IGP area, as any TE- link. During its signalling, if an upper-layer LSP makes use of a Virtual TE-link, the underlying FA-LSP is immediately signalled and provisioned. The use of Virtual TE-links has two main advantages: - flexibility: allows to compute a LSP path using TE-links and this without taking into account the actual status of the corresponding FA-LSP in the lower layer in terms of provisioning; - stability: allows stability of TE-links,TE-links in the upper layer, while avoiding wastage of bandwidth in the lower layer, as data plane connections are not established. Virtual TE-links are setup/deleted/modified dynamically, according to the change of the (forecast) traffic demand, operator's policies for capacity utilization, and the available resources in the lower layer. The support of Virtual TE-links requires two main building blocks: - A TE mechanism for dynamic modification of Virtual TE-link Topology; - A signalling mechanism for the dynamic setup and deletion of virtual TE-links. Setting up a virtual TE-link requires a signalling mechanism allowing an end-to-end association between Virtual TE-link end points so as to exchange link identifiers as well as some TE parameters. The TE mechanism responsible for triggering/policing dynamic modification of Virtual TE-links is out of the scope of GMPLS protocols. Current GMPLS signalingsignalling does not allow setting up and releasing Virtual TE-links. Hence GMPLS signalingsignalling must be extended to support Virtual TE-links. We can distinguish two options for setting up Virtual TE-links: - The Soft FA approach, that consists of setting up the FA-LSP in the control plane without actually activating cross connections in the data plane. One the one hand, this requires state maintenance on all transit LSRs (N square issue), but on the other hand this may allow for some admission control. Indeed, when a soft-FA is activated, there may be no longer available resources for other soft- FAs that were sharing common links, these soft-FA will be dynamically released and corresponding virtual TE-links are deleted. The soft-FA LSPs may be setup using procedures similar to those described in [GMPLS-RECOVERY] for setting up secondary LSPs. -The remote association approach, that simply consists of exchanging virtual TE-links ids and parameters directly between TE- link end points. This does not require state maintenance on transit LSRs, but reduce admission control capabilities. Such an association between Virtual TE-link end-points may rely on extensions to the RSVP-TE ASON Call procedure ([GMPLS-ASON]).([ASON-CALL]). Note that the support of Virtual TE-link does not require any GMPLS routing extension. 22.214.171.124. Traffic Disruption Minimization During FA Release Before deleting a given FA-LSP, all nested LSPs have to be rerouted and removed from the FA-LSP to avoid traffic disruption. The mechanisms required here are similar to those required for graceful deletion of a TE-Link. A Graceful TE-link deletion mechanism allows for the deletion of a TE-link without disrupting traffic of TE-LSPs that where using the TE-link. GMPLS protocols do not provide for explicit indication to trigger such operation. Hence, GMPLS routing and/or signaling extensions are required to support graceful deletion of TE-links. This may rely, for instance, on new signaling Error code to notify head-end LSRs that a TE-link along the path of a LSP is going to disappear, and also on new routing attributes (if limited to a single IGP area), such as defined in [GR-SHUT]. 126.96.36.199. Stability The upper-layer LSP stability may be impaired if the VNT undergoes frequent changes. In this context robustness of the VNT is defined as the capability to smooth impact of these changes and avoid their subsequent propagation. Guaranteeing VNT stability is out of the scope of GMPLS protocols and relies entirely on the capability of TE algorithms to minimize routing perturbations. This requires that the TE algorithm takes into account the old VNT when computing a new VNT, and tries to minimize the perturbation. 4.1.2. Support for FA-LSP Attributes Inheritance When FA TE-link parameters are inherited from FA-LSP parameters, specific inheritance rules are applied. This relies on local procedures and policies and is out of the scope of GMPLS protocols. Note that this requires that both head-end and tail-end of the FA-LSP are driven by same policies. 4.1.3. Support for Triggered Signaling. When a LSP crosses the boundary from an upper to a lower layer, it may be nested in or stitched to a lower-layer LSP. If such an LSP does not exist the LSP may be established dynamically. Such a mechanism is referred to as "Triggered signaling". Triggered signaling requires the following building blocks: - The identification of layer boundaries. - A path computation engine capable of computing a path containing multiple layers. - A mechanism for nested signaling. The identification of layer boundaries is supported by GMPLS routing protocols. The identification of layer boundaries is performed using the interface switching capability descriptor associated to the TE- link (see [HIER][RFC4206] and [GMPLS-RTG]).[RFC4202]). The capability to compute a path containing multiple layers is a local implementation issue and is out of the scope of GMPLS protocols. A mechanism for nested signaling is defined in [HIER].[RFC4206]. Hence, GMPLS protocols already meet this requirement. 4.1.4. FA Connectivity Verification Once fully provisioned, FA liveliness may be achieved by verifying its data plane connectivity. FA connectivity verification relies on technology specific mechanisms (e.g. for SDH, G.707, G.783, for MPLS, BFD, etc.) as for any other LSP. Hence this requirement is out of the scope of GMPLS protocols. Note that the time to establish the FA-LSP must be minimized. 4.2. Multi-Region Specific Aspects 4.2.1. Support for Multi-Region Signaling Applying the triggered signaling procedure discussed above, in a MRN environment may lead to the setup of one-hop FA-LSPs between each node. Therefore, considering that the path computation is able to take into account richness of information with regard to the Switching Capability (SC) available on given nodes belonging to the path, it is consistent to provide enough signaling information to indicate the SC to be used and on over which link. Limited extension to existing GMPLS signaling procedures is required for this purpose as it only mandates indication of the SCs to be included or excluded before initiating the LSP provisioning procedure. This enhancement would solve the ambiguous choice of SC that are potentially used along a given path, particularly in case of ERO expansion, or when an ERO sub-object identifies a multi-SC TE-link. This would give the possibility to optimize resource usage on a multi-region basis. 4.2.2. Advertisement of Internal Adaptation Capabilities In the MRN context, nodes supporting more than one switching capability on at least one interface are called Hybrid nodes. Hybrid nodes contain at least two distinct switching elements that are interconnected by internal links to provide adaptation between the supported switching capabilities. These internal links have finite capacities and must be taken into account when computing the path of a multi-region TE-LSP. The advertisement of the internal adaptation capability is required as it provides critical information when performing multi-region path computation. Figure 1a below shows an example of hybrid node. The hybrid node has two switching elements (matrices), which support here TDM and PSC switching respectively. The node terminates two PSC and TDM ports (port1 and port2 respectively). It also has internal link connecting the two switching elements. The two switching elements are internally interconnected in such a way that it is possible to terminate some of the resources of the TDM port 2 and provide through them adaptation for PSC traffic, received/sent over the internal PSC interface (#b). Two ways are possible to set up PSC LSPs (port 1 or port 2). Available resources advertisement e.g. Unreserved and Min/Max LSP Bandwidth should cover both ways. Network element ............................. : -------- : PSC : | PSC | : Port1-------------<->--|#a | : : +--<->---|#b | : : | -------- : TDM : | ---------- : +PSC : +--<->--|#c TDM | : Port2 ------------<->--|#d | : : ---------- : :............................ Figure 1a. Hybrid node. Port 1 and Port 2 can be grouped together thanks to internal DWDM, to result in a single interface: Link 1. This is illustrated in figure 1b below. Network element ............................. : -------- : : | PSC | : : | | : : --|#a | : : | | #b | : : | -------- : : | | : : | ---------- : : /| | | #c | : : | |-- | | : Link1 ========| | | TDM | : : | |----|#d | : : \| ---------- : :............................ Figure 1b. Hybrid node. Let's assume that all interfaces are STM16 (with VC4-16c capable as Max LSP bandwidth). After, setting up several PSC LSPs via port #a and setting up and terminating several TDM LSPs via port #d and port #b, there is only 155 Mb capacities still available on port #b. However a 622 Mb capacity remains on port #a and VC4-5c capacity on port #d. When computing the path for a new VC4-4c TDM LSP, one must know, that this node cannot terminate this LSP, as there is only 155Mb still available for TDM-PSC adaptation. Hence the internal TDM-PSC adaptation capability must be advertised. With current GMPLS routing [GMPLS-RTG][RFC4202] this advertisement is possible if link bundling is not used and if two TE-links are advertised for link1: We would have the following TE-link advertisements: TE-link 1 (port 1): - ISCD sub-TLV: PSC with Max LSP bandwidth = 622Mb, unreserved bandwidth = 622Mb. TE-Link 2 (port 2): - ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c, unreserved bandwidth = vc4-5c. - ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 155 Mb, unreserved bandwidth = 155 Mb. The ISCD 2 in TE-link 2 represents actually the internal TDM-PSC adaptation capability. However if for obvious scalability reasons link bundling is done then the adaptation capability information is lost with current GMPLS routing, as we have the following TE-link advertisement: TE-link 1 (port 1 + port 2): - ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c, unreserved bandwidth = vc4-5c. - ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 622 Mb, unreserved bandwidth = 777 Mb. With such TE-link advertisement an element computing the path of a VC4-4CVC4-4c LSP cannot know that this LSP cannot be terminated on the node. Thus current GMPLS routing can support the advertisement of the internal adaptation capability but this precludes performing link bundling and thus faces significant scalability limitations. Hence, GMPLS routing must be extended to meet this requirement. This could rely on the advertisement of the internal adaptation capabilitiycapability as a new TE link attribute (that would complement the Interface Switching Capability Descriptor TE-link attribute). 4.3. Client and server network aspects 4.3.1. Administrative boundary TBD 4.3.2. Path computation across separated TEDs TBD 4.3.3. Association between TE-links in separated TEDs TBD5. Evaluation Conclusion Most of the required MLN/MRN requirementsfunctions will rely on mechanisms and procedures that are out of the scope of the GMPLS protocols, and thus do not require any GMPLS protocol extensions. They will rely on local procedures and policies, and on specific TE mechanisms and algorithms. As regards Virtual Network Topology (VNT) computation and reconfiguration, specific TE mechanisms that could for instance rely on PCE based mechanisms and protocols, need to be defined, but these mechanisms are out of the scope of GMPLS protocols. Four areas for extensions of GMPLS protocols and procedures have been identified: - GMPLS signalling extension for the setup/deletion of the virtual TE-links (as well as exact trigger for its actual provisioning); - GMPLS routing and signalling extension for graceful TE-link deletion; - GMPLS signalling extension for constrained multi-region signalling (SC inclusion/exclusion); - GMPLS routing extension for the advertisement of the internal adaptation capability of hybrid nodes. 6. Security Considerations This document specifically addresses GMPLS control plane functionality for MLN/MRN in the context of a single administrative control plane partition and hence does not introduce additional security threats beyond those described in [RFC3945]. 7. Acknowledgments We would like to thank Julien Meuric and Igor Bryskin for their useful comments. 8. References 8.1. Normative [RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005. [RFC3945] Mannie, E., et. al. "Generalized Multi-Protocol Label Switching Architecture", RFC 3945, October 2004 [GMPLS-RTG][RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching", draft-ietf-ccamp-gmpls-routing, RFC4202, October 2005. [GMPLS-SIG][RFC3471] Berger, L., et. al. "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. 8.2. Informative [GMPLS-ASON][ASON-CALL] Papadimitriou, D., Farrel, A., et. al., " Generalized"Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Automatically Switched Optical Network (ASON)", draft-ietf-ccamp-gmpls-rsvp-te-ason,Calls", draft- ietf-ccamp-gmpls-rsvp-te-call, work in progess.progress. [MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux, M., Brungard, D., "Requirements for GMPLS-based multi-region and multi-layer networks", draft-ietf-ccamp-gmpls-mrn-reqs, work in progess. [HIER][RFC4206] K. Kompella and Y. Rekhter, "LSP hierarchy with generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy, FRC4206,RFC4206, October 2005. [GR-SHUT] Ali, Z., Zamfir, A., "Graceful Shutdown in MPLS Traffic Engineering Network", draft-ali-ccamp-mpls-graceful-shutdown,draft-ietf-ccamp-mpls-graceful-shutdown, work in progress. [GMPLS-RECOVERY] Lang, Rekhter, Papadimitriou, "RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery", draft-ietf-ccamp-gmpls-recovery-e2e- signaling, work in progress. [VNTM] Oki, Le Roux, Farrel, "Definition of Virtual Network Topology Manager (VNTM) for PCE-based Inter-Layer MPLS and GMPLS Traffic Engineering", draft-oki-pce-vntm-def, work in progress. [IW-MIG-FMWK] Shiomoto, K et al., "Framework for IP/MPLS-GMPLS interworking in support of IP/MPLS to GMPLS migration", draft-ietf- ccamp-mpls-gmpls-interwork-fmwk, work in progress. 9. Authors' Addresses: Jean-Louis Le Roux (Editor) France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex, France Email: email@example.com@orange-ft.com Deborah Brungard AT&T Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ, 07748 USA E-mail: firstname.lastname@example.org Eiji Oki NTT 3-9-11 Midori-Cho Musashino, Tokyo 180-8585, Japan Email: email@example.com Dimitri Papadimitriou Alcatel Francis Wellensplein 1, B-2018 Antwerpen, Belgium Email: firstname.lastname@example.org Kohei Shiomoto NTT 3-9-11 Midori-Cho Musashino, Tokyo 180-8585, Japan Email: email@example.com Martin Vigoureux Alcatel Route de Nozay, 91461 Marcoussis Cedex, France Email: firstname.lastname@example.org 10. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.