CCAMP Working Group Martin Vigoureux Internet Draft Emmanuel Dotaro Expires: December 2002 Dimitri Papadimitriou Alcatel Eiji Oki Wataru Imajuku Naoaki Yamanaka NTT June 2002 GMPLS Architectural Considerations for (Hybrid) Photonic Networks draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 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 1. Abstract Optical networks could have been reduced to point-to-point links but technology evolution led the way to an evolution trend. The concept of optical transparency first took shape through the development of photonic switching fabrics and is now being reinforced by the continuous efforts produced to increase transmission distances. Optical networking obviously can not be left aside of such evolutions and so it is for the (in particular, GMPLS-based) protocols that control these photonic networks. This document highlights the enhancements that seem to be necessary for GMPLS to cover these emerging trends (transparency, hybrid nodes) and fulfil its role of a generalized control plane. Vigoureux et al. December 2002 1 draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002 2. Summary for Sub-IP Area 2.1. Summary See the Abstract above. 2.2. Where does it fit in the Picture of the Sub-IP Work This work fits the CCAMP box. 2.3. Why is it Targeted at this WG This draft is targeted at the CCAMP WG because it proposes a first input on common signaling and routing protocol considerations in multi-service environments. 2.4. Justification of Work The WG should consider this document as it provides an architectural framework for GMPLS-capable multi-service (with shared regeneration) environments, topic that attracts increasing attention over past years from the engineering community. 3. 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. 4. Introduction Optical networks could have been reduced to point-to-point links but technology evolution led the way to an evolution trend. The concept of optical transparency first took shape through the development of photonic switching fabrics and is now being reinforced by the continuous efforts produced to increase transmission distances. Matching these evolutions, are the efforts made at the CCAMP WG for the definition a generalized control plane architecture to encompass the networking issues that arise in such networks. In parallel to the introduction of heterogeneous networks with limited conversion/regeneration functions, optical networks are going beyond the restrictive transport function they first proposed. Nodes are evolving to integrate multiple switching capabilities jointly controlled in order to propose enhanced inter-working, leading to resource utilization optimization. Such multi-level switching architectures can be composed, for example, of a photonic switch fabric topped by an opaque one offering regeneration function and switching at another granularity. These architectures will be referred in this document to as Hybrid Photonic Architectures (HPAs) Vigoureux et al. December 2002 2 draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002 and the corresponding networks to as Hybrid Photonic Networks (HPNs). Optical networking obviously can not be left aside of such fundamental evolutions and so it is for the (in particular, GMPLS- based) protocols that control these photonic networks. Work ongoing at the IPO working group reflects the need to consider topological as well as physical constraints of photonic networks (see [IPO- IMP]). Unique aspect of hybrid photonic networks ----------------------------------------- In hybrid photonic environments, constraints such as resource availability are of utmost importance where regeneration/conversion functions are limited and shared. In HPNs, resources are no longer symmetrical with respect to regeneration/conversion functions. This feature deeply impacts wavelength selection schemes (i.e. spectral path computation) as well as wavelength continuity that will be harder to achieve. This, in addition to the selection of regeneration points conditioned by resource availability and signal degradation. This document highlights the enhancements that seem to be necessary for GMPLS to cover these emerging trends (transparency, hybrid nodes) and fulfil its role of a generalized control plane. The first part of the document gives an overview of the impact of optical transparency issues on signaling and how can they be addressed. The second part is dedicated to routing considerations while the third focuses on signaling. 5. Different Approaches Establishing a connection throughout an optical network is achieved in two steps: determination of an explicit spatial route followed by a signaling phase selecting network resources (e.g. sequence of wavelengths) to be used by the LSP. In this document, these two phases are respectively referred to as spatial routing and spectral routing. The different schemes (see also [ONM-1]) listed below tend to address the issues arising from the introduction of transparency in optical networks. The impact of each scheme on the protocol architecture is detailed afterwards. 5.1. First Scheme The ingress node performs spatial and spectral routing decision. Due to link-state scalability issues (and if the spectral routing related information is not fed through the backward signaling flow), this scheme is not considered in the current context. Vigoureux et al. December 2002 3 draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002 5.2. Second Scheme The ingress node performs spatial routing, while the intermediate nodes perform spectral routing (hop-by-hop label selection is part of spectral routing). As currently specified, the GMPLS protocol suite definition reflects this scheme. Per [GMPLS-SIG], the Label Set selection works according to an AND scheme (see also [OKI-IPO]). Each hop restricts the Label Set sent to the next hop from the one received from the previous hop by performing an AND operation between the wavelength referred by the labels it includes with the one available on the ongoing interface. The constraint to perform this AND operation is up to the node local policy (even if one expects a consistent policy configuration throughout a given transparency domain). When wavelength conversion is performed at an intermediate node, a new Label Set is generated. The egress nodes selects one label in the Label Set received at the node. According to the selected label for the incoming link at the egress node, each label on the route is determined in a hop-by-hop manner. 5.3. Third Scheme The ingress node performs spatial routing while the egress node performs spectral routing. Here, intermediate nodes may be allowed performing some local processing. Spectral related information is fed through signaling downward to the egress node according to an ALL scheme (see also [OKI-IPO]). For this purpose, at each hop, a Label Set object/TLV may be appended to the global Label Set (more precisely to the list of Label Set objects defining an end-to-end significant Label Set). Additional processing may be performed at intermediate nodes depending on local constraints. At the end of the process and according to the collected spectral information, the egress node determines all the labels on the route considering the (individual) local constraints. 6. Routing Enhancements All the previously listed schemes share the common approach of performing spatial routing at ingress. The computation of the spatial route is done upon information flooded by an IGP such as OSPF or ISIS (see for OSPF [OSPF-TE], and [GMPLS-OSPF] and for IS-IS [ISIS-TE] and [GMPLS-ISIS]). Obviously, the more precise the information is, the more deterministic the result is. However, assumption is made that periodical flooding and link state information processing is not scalable if performed at component link level. This statement might also depend on the frequency of the update. Moreover, maintaining a routing adjacency Vigoureux et al. December 2002 4 draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002 for each component link seems not realistic also for the same scalability reasons. Therefore, the use of TE Links with stochastic resource selection may be thus retained in this context. Several constraints have already been envisaged to be taken into account for constraint based spatial path computation. Bandwidth availability and switching capability are, for example, information available via TE Link Sub-TLVs (see [GMPLS-RTG]). However, it may be appropriate to complete this information in order to reflect enhanced link characteristics but also hybrid photonic network features. 6.1.1. Physical Constraints Due to the limited number of (shared) regeneration capability in HPNs, physical constraints have to be considered during spatial routing. Since physical impairments (see for instance [IPO-IMP]) may be relevant at the wavelength granularity, the latter requirement is confronted to the same scalability problem if this information is to be flooded by a link state routing protocol. A solution would be to appropriately aggregate physical impairment information at the TE Link level. This would enable providing a summarized information on signal degradation enabling TE Link selection during the LSP path computation. However, if the considered physical impairments are nearly static or have long variation period they may not be flooded and just made available for path selection by using another mechanism such as using the management plane. Otherwise means to aggregate physical impairments information and to disseminate this information will be needed. 6.1.2. Shared Resources Availability In photonic networks, taking into account physical impairments during spatial routing without any information about regeneration is of little relevance. It is considered that the regeneration capability information will be flooded by a link state routing protocol such as OSPF or ISIS. In HPNs, regeneration resources are distributed between optical nodes and thus limited in terms of number of sharable entities. The information relative to regeneration resources availability is thus of a statistical nature if given at the TE link level. Thus one expects to be capable to apply a stochastic approach for the regeneration resource availability (defining implicitly their status). 6.1.3. Waveband Switching Vigoureux et al. December 2002 5 draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002 GMPLS protocol suite, as currently defined, supports waveband switching through inverse multiplexing or switching of individual (contiguous) wavelength components. It may be thus appropriate to integrate wavebands in the switching hierarchy in order to reflect, at the control plane level, waveband physical components (multiplexer/demultiplexer) availability at the data plane. Detailed extensions are described in [GMPLS-WBEXT]. Depending on the (passive/active) components used in an optical network, wavelength spacing in the optical multiplex can vary. Some components like multiplexer/demultiplexer impose or depend on that spacing. It may be thus appropriate to detail the component capability with respect to spacing, or to indicate the number of supported wavelengths per waveband. Moreover, one may also expect in case of (standardized) waveband nominal frequency values some simplification during the corresponding wavelength assignment. 7. Signaling Considerations The previous section highlighted the considerations with respect to the routing protocols for enabling constraint based spatial routing in hybrid photonic environments. The current section focuses on the impact of HPNs on signaling architecture by detailing spectral routing schemes mentioned above. 7.1. Schemes Comparison In case of the second scheme (see Section 5.2.), the Label Set reduction works according to an AND scheme. Each hop restricts the label set sent to the next hop from the one received from the previous hop by performing an AND operation between the wavelengths referred by the Labels it includes the one available on the ongoing interface. This method generates a strong issue with regards to the probability of having the Label Set reduced to an empty set of labels before reaching the egress node (if each hop only proposes Labels referring to wavelengths that are neither converted nor regenerated). Note that using crank-back procedure can help reducing blocking probability. A node may initiate a crank-back procedure if all wavelengths referred in the Label Set coming from the upstream node are not usable on the outgoing links to the downstream node. - If conversion capabilities are available at this node and accessible by the wavelengths referred in the Label Set coming from the upstream node, the node may propose a new Label Set including Labels accessible through conversion. - If conversion functions are either not available in the node or/nor accessible by the wavelengths referred in the Label Set coming from the upstream node, the node may send a message (including the Acceptable Label Set) to the upstream nodes in order for the latter to propose new Labels (via conversion). Vigoureux et al. December 2002 6 draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002 This message should contain an Acceptable Label Set (used as feedback) for upstream nodes to intelligently propose new Labels. Crank-back may reduce blocking probability but generates an issue concerning signaling messages that may go back to the source and forth many times before spectral path is found. Consequently, an additional improvement should target intermediate Label Set initialization point as (intermediate) destination of such messages in order to avoid that the source (located behind the initialization point) takes a contradictory decision based on the Acceptable Label Set information. Moreover, it can be demonstrated that Label Set utilization according to the AND scheme with crank-back feature is sub-optimal with regards to the minimization of the number of conversion/ regeneration points along the path. Nevertheless, in the same context, only a global knowledge of spectral resources availability along the spatial path enables optimal spectral path computation. It may be thus proposed to feed this information through signaling using Label Set combined with an ALL scheme (i.e. also referred to as exhaustive schemeE and do spectral path computation at the egress node. This refers to third scheme. Note that the exhaustive property may be relaxed according to a local policy in order to reduce the amount of information exchange from the source to the destination (i.e. over the entire LSP). At each hop, the local Label Set object/TLV is appended to the Label Set (more precisely to the list of Label Let objects). Additional processing might be done at intermediate nodes depending on local constraints and policy. The egress node receives the spectral information collected along at least one spatial path. It can then compute, using this spectral information, the optimal combination or transparent sub-paths. The third scheme has an added value compared to the second one. It enables ensuring (a better) wavelength continuity while jointly addressing regeneration needs along the path, though it requires having the knowledge (at egress) of the ability a node to access regeneration for a given wavelength. The issue here is to make a clear differentiation between a Path message with resource reservation and a so-called probing message, defined as a message only probing for the resource availability. For that purpose an additional status of the request can be defined in the signaling protocol (for instance a specific Administrative status flag, other solutions may also be considered). So the following method can be considered: - Path/Label Request message(s), along several but at least one spatial explicit routes computed at ingress. Vigoureux et al. December 2002 7 draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002 - Computation at the egress of the best combination of transparent sub-paths. (Wavelength Labels containing the necessary information for this purposes) - Resv/Label Mapping message through the selected path - PathErr/Notification messages to the non-selected path (if one considers that releasing the reserved resources must be performed) Note: Wavelength Selection and Reservation Downstream Wavelength Selection and Reservation can only be considered with Selective AND scheme. The ALL Scheme with forward (downstream) reservation is precluded since it would generate an overwhelming blocking probability, so this method can only be used with a backward (upstream) reservation. Nevertheless, Soft Selection (control plane only) can be considered either with a Selective AND and Exhaustive ALL scheme. 7.2. Wavelength Label Space and Values As specified in [GMPLS-SIG], the Wavelength label space may include either absolute values (channel identifiers (Channel ID) also referred to as wavelength identifiers) or relative values (channel spacing also referred to as inter-wavelength spacing). The latter is strictly confined to a per-port label space while the former could be defined as a local or a global (per node) label space. However, both wavelength selection schemes listed above require the knowledge of the mapping between collected Labels and the wavelength spectral-related information they locally refer. Therefore, in this context, it is proposed to define an association between the Label value and the wavelength spectral information. In the second scheme, upstream nodes receiving an Acceptable Label Set message, due to the crank-back procedure, must be able to understand which wavelengths these Labels refer to. In third scheme, the egress node must also know which wavelengths the Labels refer to in order to achieve the expected wavelength continuity. In order to decide where regeneration/conversion should be ideally performed because of signal degradation/blocking probabilities, knowledge of the capability of a wavelength to be regenerated is also important. The definition of the association between the Label value and the wavelength spectral information is achieved by specifying semantic- full and dedicated fields in the 32 bits Label. This specification simply corresponds to a Label value assignment rule and still ensures backward compatibility for nodes not able to understand the hereafter defined semantic. Vigoureux et al. December 2002 8 draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002 This Label may for instance include the following information reflecting the spectral capabilities and attributes of the selected Label: R : set by the node proposing the Label. Informs whether the corresponding wavelength can be regenerated or not. C : set by the node proposing the Label. Informs whether the corresponding wavelength can be converted or not. A : set by the next downstream node receiving the proposed Labels. Informs whether wavelengths can have access to regeneration functionality in this node. This indication is primarily used by nodes presenting blocking architectures with respect to their amplification capabilities. For instance, amplification can be performed in the C-Band, L-Band, S-Band, etc. Wavelength Index : Identifies the wavelength in the Amplification Band by considering minimum spacing. Wavelength Identifier : Used to differentiate Labels (proposed for example in a Label Set) that would have same values of the fields listed above. Other definitions not detailed here may also be used for the same purpose. It should be also noticed that such label space definition does not in the absolute sense bring any backward compatibility issue with respect to [GMPLS-SIG]. In particular one assumes here that local node may still convert these values into an internal one no specific procedures should be defined to achieve backward compatibility. 7.3. Comparison Example The following example illustrates the different results that may be obtained, for a spectral path computation, when using the second and third schemes. Consider a spatial path composed of nine wavelength switching nodes with shared converters (both in the optical domain). In this example, only available resources are mentioned and are described as follows: - Li-T means that interface i is transparent (neither going through a converter converted nor a regenerator) - Lj-C means that interface j is converted Note that in case of nodes having conversion on all interfaces, the second scheme is still compatible. Available wavelengths on the outgoing links and thus not requiring conversion (even though going through a converter) are considered as transparent and corresponding Labels can thus be proposed. Vigoureux et al. December 2002 9 draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002 Node 1 has available L2-C and L4-C Node 2 has available L4-T and L6-C Node 3 has available L4-T and L6-T Node 4 has available L4-T, L6-T and L7-C Node 5 has available L4-T, L6-T and L7-T Node 6 has available L6-T and L7-T Node 7 has available L6-T and L7-T Node 8 has available L6-T and L8-C Node 9 has available L6-T and L8-C For second scheme (with crank-back) wavelength selection will go as follows: Node 1 proposes the Labels L2 and L4 that Node 2 restricts to L4 (only transparent wavelength). Reaching Node 5, the Label L4 is sent towards Node 6, which has free output interfaces but no available conversion function. Message is thus sent back upstream (maybe with an Acceptable Label Set, L6 and L7 in this case) until a node can perform conversion. Therefore, the feedback (i.e. the Acceptable Label Set) is used by Nodes having enough free resources to perform wavelength conversion. Here, the message arrives back to Node 4 which can perform conversion from L4 to L7. Node 4 sends Label Set L7 which is propagated down to Node 8. L7 is not available at Node 8 output but can be converted to L8 (Node 8 does crank-back on itself). The resulting spectral path can be represented as: L4 L4 L4 L7 L7 L7 L7 L8 N1------N2------N3------N4------N5------N6------N7------N8------N9 Using the third scheme, each node, proposing all of its free output Labels, the result would have been: L4 L6 L6 L6 L6 L6 L6 L6 N1------N2------N3------N4------N5------N6------N7------N8------N9 Therefore, the second scheme will result in using two conversion points (at Node 4 and Node 8) along the path, while third scheme will result in using only one (at Node 2). 8. Other issues This section details other GMPLS architectural issues in the scope of the hybrid photonic networks: 8.1 Bi-directional LSPs When using the second selection scheme, two mechanisms must be considered depending on the directionality of the LSP: 1) Unidirectional LSP: (downstream) label set 2) Bi-directional LSP: (downstream) label set and upstream label Vigoureux et al. December 2002 10 draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002 The first improvement that may be provided is to extend the upstream label to an upstream label set, thus one would have the following symmetric approach when using an AND label selection scheme: 1) Unidirectional selection scheme: (downstream) label set 2) Bi-directional selection scheme: (downstream) label set and upstream label set The Resv/Label mapping message will then either include the downstream label in addition to the upstream label, in case of bi- directional LSP. Notice that here both labels are selected at the egress. Detailed extensions concerning the upstream label set are described in [OKI-UPSTREAM]. The same applies in case of exhaustive label selection scheme. The ALL scheme when used for bi-directional path setup must take into account not only outgoing spectral routing information but also incoming spectral routing information and perform the selection at the destination based on a correlation basis for both upstream and downstream flows. 8.2 Prioritized Label Sets Signaling extensions may be also considered to ease forward-link label unavailability when the downstream label selection is restricted by the upstream node using the Label Set (see [GMPLS- SIG]). [OZU-FLAGS] allows relaxing backward-link label collision by introducing a Flagged Label Set object/TLV in order to prioritize the reservation of the labels included in the Label Set and enabling to decrease the forward- and backward-link blocking probability. In order to prioritize the label reservation, each set of labels is inserted by each hop along the path into the Flagged Label Set with a certain priority. Each node keeps track of each label by using a local timestamp indicating when the label has been reserved but not selected yet with respect to any other previous label set. A pool points to these labels and provides a gray area for the labels, which are subject to collision. It may be seen as an intermediate state between the labels belonging to the used pool of labels (reserved and selected) and the ones belonging to the available pool of labels (neither reserved nor selected). Other prioritization methods may be considered in future releases of this document. 8.3 Branching and K-(C)SPF TBD. 9. Security Considerations This memo does not introduce new security consideration from the ones already detailed in the GMPLS protocol suite. Vigoureux et al. December 2002 11 draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002 10. References [GMPLS-ARCH] E.Mannie (Editor) et al., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", Work in progress, draft-ietf-ccamp-gmpls-architecture-02.txt [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al., "IS-IS Extensions in Support of Generalized MPLS", Work in progress, draft-ietf-isis-gmpls-extensions-12.txt [GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al., "OSPF Extensions in Support of Generalized MPLS", Work in progress, draft-ietf-ccamp-ospf-gmpls-extensions-07.txt [GMPLS-SIG] Ashwood-Smith, P. et al., "Generalized MPLS-Signaling Functional Description", Work in progress, draft-ietf-mpls-generalized-signaling-08.txt [GMPLS-RTG] Kompella, K., Rekhter, Y., Banerjee, A. et al., "Routing Extensions in Support of Generalized MPLS", Work in progress, draft-ietf-ccamp-gmpls-routing-04.txt [GMPLS-WBEXT] Douville R. et al., "Extensions to Generalized MPLS for Waveband Switching", Work in progress, draft-douville-ccamp-gmpls-waveband-extensions-01.txt [IPO-IMP] A. Chiu et al., "Impairments And Other Constraints On Optical Layer Routing", Work in progress, draft-ietf-ipo-impairments-02.txt. [ISIS-TE] Smit, H., Li, T., "IS-IS Extensions for Traffic Engineering", Work in progress, draft-ietf-isis-traffic-04.txt [OKI-IPO] E. Oki et al., Requirements of optical link-state information for traffic engineeringE Work in progress, draft-oki-ipo-optlink-req-00.txt [OKI-UPSTREAM] E. Oki et al., Upstream Label Set Support in RSVP-TE extensionsE Work in progress, draft-oki-ccamp-upstream-labelset-00.txt Vigoureux et al. December 2002 12 draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002 [OZU-FLAGS] T.Ozugur et al., Label Set Priority and Flagging OperationsE Work in progress, draft-ozugur-ccamp-gmpls-label-flag-00.txt [ONM-1] A comparative study of distributed protocols for wavelength reservation in WDM Optical networks, Optical Network Magazine, January 2002. [OSPF-TE] Katz, D., Yeung, D., "Traffic Engineering Extensions to OSPF", Work in progress, draft-katz-yeung-ospf-traffic-06.txt 11. Acknowledgments We would like, here, to thank Richard Douville, Olivier Audouin, Emmanuel Desmet as well as Amaury Jourdan and Bernard Sales. The authors would like also to thank Kohei Shiomoto and Nobuaki Matsuura of NTT for their contribution to this memo. 12. Author's Addresses Eiji Oki (NTT) 3-9-11 Midori Musashino, Tokyo 180-8585, Japan Email: oki.eiji@lab.ntt.co.jp Wataru Imajuku (NTT) 1-1 Hikari-no-oka Yokosuka, Kanagawa 239-0847, Japan Email: imajuku@exa.onlab.ntt.co.jp Naoaki Yamanaka (NTT) 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585, Japan Email: yamanaka.naoaki@lab.ntt.co.jp Emmanuel Dotaro (Alcatel) Route de Nozay, 91460 Marcoussis, France Phone: +33 1 6963-4723 Email: emmanuel.dotaro@alcatel.fr Dimitri Papadimitriou (Alcatel) Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 Email: dimitri.papadimitriou@alcatel.be Martin Vigoureux (Alcatel) Route de Nozay, 91460 Marcoussis, France Phone: +33 1 6963-1852 Vigoureux et al. December 2002 13 draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002 Email: martin.vigoureux@alcatel.fr Vigoureux et al. December 2002 14 draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." Vigoureux et al. December 2002 15