diff options
Diffstat (limited to 'doc/rfc/rfc3604.txt')
| -rw-r--r-- | doc/rfc/rfc3604.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc3604.txt b/doc/rfc/rfc3604.txt new file mode 100644 index 0000000..cbb57c0 --- /dev/null +++ b/doc/rfc/rfc3604.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group H. Khosravi +Request for Comments: 3604 Intel +Category: Informational G. Kullgren + S. Shew + Nortel Networks + J. Sadler + Tellabs + A. Watanabe + NTT + October 2003 + + + Requirements for Adding Optical Support to + the General Switch Management Protocol version 3 (GSMPv3) + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This memo provides requirements for adding optical switching support + to the General Switch Management Protocol (GSMP). It also contains + clarifications and suggested changes to the GSMPv3 specification. + +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 BCP 14, RFC 2119 [1]. + +1. Overview + + This document details the changes to GSMP necessary for the support + of optical (non-transparent and all optical), SONET/SDH, and spatial + switching of IP packets, Layer 2 (L2) frames and TDM data. When + implemented, GSMP controllers will then be able to control: photonic + cross-connects (optical-optical), transparent optical cross connects + (optical-electrical-optical, frame independent), opaque cross + connects (optical-electrical-optical, SONET/SDH frames), and + + + + + +Khosravi, et al. Informational [Page 1] + +RFC 3604 Adding Optical Support to GSMPv3 October 2003 + + + traditional TDM switches (all electrical). The resulting systems + could form IP based optical routers, optical label switches, + wavelength routers, and dynamic optical cross connects. + + Several different generic models exist defining how to provide + control plane functionality in an optical network [2], [3], [4]. + This document takes no position on which model is most appropriate + (e.g., single or multiple routing plane instances). The only + assumption is that the ability to separate the control mechanisms + from the data switching is as useful for the signaling of optical + paths (e.g., GMPLS) as it is for the signaling of L2 paths (e.g., + MPLS). Therefore, the requirements contained within are focused only + on the separation of control functions from data functions in order + to provide a more flexible network architecture. + + GSMPv3 [5] is well suited for providing the control interface + necessary for allowing an IP based controller to direct the + activities of an optical switch. In order for GSMP to operate + between controllers and optical switches and cross connects, support + for optical labels and service and resource abstractions must be + added to GSMP. + + This document also includes changes recommended by implementers that + will facilitate easier development of a GSMP implementation. These + changes consist of rearranging PDU formats, clarification of flags, + transaction identifiers, and response codes. + +2. Requirements for Optical Support + +2.1. Label + +2.1.1. Label Types + + New labels are needed to identify the entities that are to be + switched in the optical fabric. These are longer than the labels + defined in GSMPv3 as they have physical and structural context. As + GMPLS [2], [3] has had very similar requirements for label formats, + alignment with GMPLS is proposed. This includes support for: + + - Digital Carrier Hierarchy (e.g., DS-1, E1) + - SONET and SDH Hierarchy (e.g., OC-3, STM-1, VT1.5, VC-12) + - Plesiochronous Data Hierarchy (PDH) labels [6] + - OTN G.709 labels + - Lambdas + - Fibers + + + + + + +Khosravi, et al. Informational [Page 2] + +RFC 3604 Adding Optical Support to GSMPv3 October 2003 + + + GSMP MUST include support for all label types list above, as well as + for label hierarchies and label lists as defined by GMPLS. + Therefore, the ability to perform operations on groups of the above + labels MUST also be supported (e.g., 5 OC-3s, contiguous wavebands). + +2.1.2. Label Management Issues + + An updated label range message MUST be provided. There MUST also be + support of multiplexing (e.g., no multiplexing, SONET, Gigabit + Ethernet multiplexing etc). + +2.2. Statistics messages + + Optical switches have a number of different statistics which are not + in common with ATM, or Frame Relay switches. Consequently, the + statistics messages SHOULD be updated to report Performance + Monitoring statistics defined for all new optical transport + technologies added to GSMP. + +2.3. Configuration Issues + +2.3.1. Switch Configuration + +2.3.1.1. Layer Switching Identification + + Since an Optical Switch may be able to provide connection services at + multiple transport layers (i.e., STS-3c, STS-1, VT-1.5, DS3, DS1), + and not all switches are expected to support the same transport + layers, the switch will need to notify the controller of the specific + layers it can support. + + Therefore, the Switch Configuration message MUST be extended to + provide a list of the transport layers for which an optical switch + can perform switching. + +2.3.2. Port Configuration + + The port configuration message supplies the controller with the + configuration information related to a single port. Consequently, + extensive additions will need to be made to this command. + + + + + + + + + + + +Khosravi, et al. Informational [Page 3] + +RFC 3604 Adding Optical Support to GSMPv3 October 2003 + + +2.3.2.1. Port Type extensions + + Port types MUST be added to support the mix of optical signals that + can operate over a single fiber. + + The port information that MAY need to be conveyed includes [7]: + + - wavelengths available per interface + - bit rate per wavelength + - type of fiber + +2.3.2.2. Supported Signal Type extensions + + Since a port on an optical switch may support signals at multiple + transport layers, it is necessary to understand the signals + supported, as well as the possible ways that one signal can be + transported within another. + + For OTN, SONET/SDH and PDH optical switches, the Port configuration + message MUST be extended to detail the different transport layer + signals that are supported by a port. Furthermore, this extension + MUST detail which signals may be transported by another signal. + + This mechanism MUST also provide information about optional + capabilities (such as virtual concatenation and arbitrary + concatenation for SONET/SDH) available on a port. + +2.3.2.3. Trace Mechanism support Identification + + A number of transport layer signals include overhead channels that + can be used to identify the source of a signal. Since they are + embedded in the signal, only the network element has access to the + signals. However, not all network elements have the capability to + set or read the messages in these channels on every port. + Consequently, this port attribute needs to be reported to the + controller. + + The Port Configuration message MUST be extended to report which trace + mechanisms are supported by a port. + +2.3.2.4. Port Location Identification + + Since contemporary Optical switches have the ability to support tens + of thousands of ports in hundreds of shelves located in as + potentially as many bays, the current "Slot/Port" location identifier + is inadequate. + + + + + +Khosravi, et al. Informational [Page 4] + +RFC 3604 Adding Optical Support to GSMPv3 October 2003 + + + The Slot/Port Location Identifier MUST be extended to encode + Bay/Shelf/Slot/Port. + +2.3.2.5. Port-related Partitioning Extensions + + Partitioning can be done for any resource that exists in the network + element. The GSMP partitioning draft currently defines ports and + switching resources as partitionable resources. Since optical + switches may support multiple transport network layers, an additional + resource type is introduced: the transport layer signal. + + The point where a transport layer signal is inserted into a lower + layer signal (called an "access point" by the ITU [8]), is very + similar to a port. Therefore, when partitioning is done on a + transport layer signal basis, the partition that is the user of the + access point MUST have a port that associated with the access point. + Labels will then be used in the to describe the subordinate signals. + +2.3.3. Service Configuration + + While new capability sets MUST be added to support quality parameters + in optical switches, no changes are foreseen to the service + configuration message as its role to carry the service information as + defined in the applicable service model. + +2.4. Service Model Issues + + While one assumption of using optical media is that bandwidth is + plentiful, it should be expected that traffic engineering will be + necessary in any case [5]. GSMP provides the means for each + connection to be created with specific attributes. Therefore, + service parameters will need to be defined for each of the Different + Optical technologies. + +2.4.1. Transparent Optical + + Capability to control re-timing and re-shaping on a per port level + MUST be added. + +2.4.2. SONET/SDH and OTN + + The capability to control the adaptation parameters used when a + transport signal is inserted into another transport signal MUST be + added. These parameters SHOULD be modifiable at times other than + adding a branch so that functions such as Tandem Connection + Monitoring can be configured. Currently, the default set of service + models in GSMP are all based on the services models defined + elsewhere, e.g., the Intserv model [9], [10], the Diffserv [11] + + + +Khosravi, et al. Informational [Page 5] + +RFC 3604 Adding Optical Support to GSMPv3 October 2003 + + + model, ATM QoS models and the Frame relay forum QoS models. A + determination needs to be made of the applicable service models for + optical channel trails. These models MUST then be mapped to the GSMP + capability set mechanism. + +2.5. Encapsulation issues + + The working group needs to decide whether a new encapsulation is + required. In other words, will all optical switches used in either + the MPLS over Optics and the IP over optics applications require that + IP be implemented on the control channel connecting the GSMP + controller and Optical switch (the GSMP target). + + A new encapsulation SHOULD be defined allowing the use of a non-IP + raw wavelength control connection. + + Likewise, a new encapsulation SHOULD be defined allowing GSMP to be + used in legacy Data Communication Network (DCN) environments that use + OSI CLNP. + + The security risks of additional non-IP encapsulations MUST be + described, since the mandatory to implement mechanism of IPsec is not + available for these control channels, as in the RFC 3293 Ethernet and + ATM cases. It is in scope to perform risk analysis and describe if + mechanisms for link-level security mitigate the risk. + +2.6. MIB Issues + + If a new encapsulation is defined, then the encapsulation group + SHOULD be updated. No other changes should be required. + +2.7. OXC Transaction Model + +2.7.1. Serial Transactions + + Many existing OXCs use a command interface which assumes a serial + transaction model. That is, a new command cannot be issued or + processed until the existing command is completed. Under + provisioning control via a network management application, and with + non-dynamic path setup, this model has been adequate. + + Moving to a dynamic path setup capability with a distributed control + plane, a parallel transaction model is likely required for + performance. This is particularly helpful when the performance of + setting up a TDM style connection is much slower than setting up an + L2 connection table. If the OXC is not able to support a parallel + transaction model, a GSMP controller MUST be informed of this and + adopt serial transaction behavior. + + + +Khosravi, et al. Informational [Page 6] + +RFC 3604 Adding Optical Support to GSMPv3 October 2003 + + +2.7.2. Bulk Transactions + + Again due to the time it may take some OXCs to setup TDM connections + relative to L2 fabrics (e.g., VC-4/STS-1 SPE fabric in an HOVC/STS + switch), support for sending multiple transactions in the same + message is a useful optimization. When an OXC receives a bulk + message, the individual transactions are acted upon and a single + reply is sent. If parallel transactions are not supported, bulk + messages can improve performance by reducing transaction overhead. + Bulk transactions SHOULD be supported. + +2.8. OXC Protection Capabilities + + To achieve good link protection performance (e.g., 50 ms after + failure detection), SONET/SDH and some OXC systems use hardware based + protection schemes (e.g., ring protection). Achieving this level of + performance solely using a data control plane such as GMPLS is a + serious challenge. An alternate approach is to utilize protection + capabilities of an OXC with a dynamic control plane. An implication + of this hybrid approach is that extensions are needed to GSMP to + provision the behavior of an OXC in anticipation of a link failure. + + This differs from the strict master-slave relationship in GSMP for + Layer 2 switches in that here the OXC is capable of taking an action + independent of the GSMP controller and then informing the controller + afterwards. Consequently, the GSMP port configuration command MUST + be extended to allow autonomous protection behaviors to be + provisioned into the Network Element. + + Furthermore, the controller MUST be able to provide the parameters + for when reversion from a backup link to the original link is + allowed. This may take the form of hold-off timers, BER parameters, + or the requirement for controller directed reversion. + +2.8.1. Non-Reserved Protection Links + + An example of protection OXC behavior is that when a link fails, a + backup link may be used to protect traffic on. This backup link + could be selected from a set of links, none of which are pre- + reserved. A backup link could be shared with one or more "working" + links which is a form of 1:n shared protection. Specifying the set + of possible backup links SHOULD be done as an option to the Add- + Branch message. + + + + + + + + +Khosravi, et al. Informational [Page 7] + +RFC 3604 Adding Optical Support to GSMPv3 October 2003 + + + When a backup link is used or the OXC reverts back to the original + link, the control plane (i.e., signaling) may need to know about the + new path state in order to notify the operator, or take some other + OAM action (e.g., billing, SLA monitoring). An additional GSMP + message to inform the controller SHOULD be added to do this. + +2.8.2. Dedicated Protection Links + + A more specialized form of restoration called "1+1" defines a + (usually node disjoint) protection path in a transport/optical + network for a given working path. At the ingress node to the path, + the traffic signal is sent simultaneously along both working and + protection paths. Under non-failure conditions at the egress node, + only the last link of the working path is connected to the client. + When any link in the working path fails, traffic on the working path + ceases to be received at end of the path. The egress OXC detects + this condition and then switches to use the last link of the + protection path without the controller having to issue a Move-Input- + Branch message. At no time is the ingress node aware which link the + egress node is using. Selection of the protection path and all of + its links is outside the scope of GSMP. + + Specification of the two output branches at the ingress node can be + done with the usual Add-Branch semantics. The ingress node + protection link is not shared with any other working link. + + Specification of the two input branches at the egress node should be + done when the Add-Branch message is sent. This SHOULD be an option + to that message. The egress node protection link is not shared with + any other working link. + + When a protection link is used or the OXC reverts back to the working + link, the control plane (i.e., signaling) may need to know about the + new path state in order to notify the operator, or take some other + OAM action (e.g., billing, SLA monitoring). An additional GSMP + message to inform the controller SHOULD be added to do this. + + If an alternate input port is not specified with an original Add- + Branch message, it MAY be specified in a subsequent Add-Branch + message. In this case, it is useful to include information about + existing users of the output port in that Add-Branch message. This + helps the OXC immediately learn of the association between the new + input port and an existing one. The association is used to enable + OXC protection procedures. This capability MUST be added to the add- + branch message. + + + + + + +Khosravi, et al. Informational [Page 8] + +RFC 3604 Adding Optical Support to GSMPv3 October 2003 + + + Similar contextual information is needed for a Delete-Branch message + so that the OXC can determine if a path becomes unprotected. This + capability MUST be added to the Delete-branch message. + +2.8.3. Protection Triggers + + Aside from link or equipment failures, there are a variety of + maintenance conditions that could cause the backup/protection link(s) + to be used. These may include: + + - Scheduled maintenance of the working link. Here the network + operator deliberately takes a link out of service to perform + maintenance. + - Reconfiguration of fiber/node/network which causes temporary need + to use backup links. + + It may be useful to specify these triggers when the backup/protection + links are defined with the Add-Branch message. This depends on how + the OXC is implemented to be aware of such triggers. This is for + further study. + +2.8.4. Protection Link Capabilities + + When an OXC has the capability to perform protection switching + independently from the Optical Call Controller (OCC), it may be + useful for the OCC to be informed of these capabilities at switch + and/or port configuration. Applications in the GSMP controller could + use this information. For example, signaling clients could define a + path protection scheme over multiple GSMP enabled OXCs. This is for + further study. + +2.9. Controller directed restoration + + Bi-directional Connection Replacement + + Connections in the transport network are inherently point-to-point + bi-directional. Unfortunately, GSMPv3 currently does not allow for + the B and R flags to be set on an add branch message. This means + that it is not possible to do an atomic replacement of a bi- + directional connection -- an action that is desirable for controller + directed restoration. Consequently, the protocol MUST be changed to + allow these flags to be used at the same time. + + + + + + + + + +Khosravi, et al. Informational [Page 9] + +RFC 3604 Adding Optical Support to GSMPv3 October 2003 + + +2.10. Support for optical burst switching + + GSMP for Optical Switching should also support optical burst + switching. As described in [12], [13], and [14], part of burst + switching connection setup includes reserving time on the transport + medium for the client. + + This time is characterized by two parameters: a start time and the + duration. These values MAY define a one-time reservation or a + repeating reservation. Upon a request for setup of a burst + connection, the GSMP controller MUST perform appropriate Connection + Admission Control for the time and duration specified and, if the + connection is allowed, MUST signal these parameters to the burst + switching device to reserve the exact bandwidth required [12], [14]. + The burst switch MUST perform the switching operation autonomously, + using the synchronization methods prescribed for the burst network it + is operating in. + +3. Requirements from Implementers + + This section describes requirements to GSMP v3 based on some + implementation experience. They address areas of ambiguity, missing + semantics, and configuration recommendations. + +3.1. GSMP Packet Format + + The Basic GSMP Message Format in chapter 3.1.1 in [5] describes the + common fields present in all GSMP messages except for the Adjacency + protocol. + +3.1.1. Message segmentation + + If a message exceeds the MTU of the link layer it has to be + segmented. This was originally done with the "More" value in the + Result field. The addition of the I flag and the SubMessage Number + to the header has made the "More" value obsolete. + + The I flag and SubMessage numbers should be used in all messages that + can be segmented. + +3.1.1.1. SubMessage Number and I flag + + It should be specified if the SubMessage Number starts on 0 or 1 in a + segmented message and what value the I flag should have in an message + that is not segmented. + + + + + + +Khosravi, et al. Informational [Page 10] + +RFC 3604 Adding Optical Support to GSMPv3 October 2003 + + +3.1.1.2. Message Length + + Clarification of what value should be used in the Length field for + segmented messages. Specifically, does the Length field contain the + total length of the message or the length of the current segment. + +3.1.1.3. Message Segmentation example + + To avoid all ambiguity an example of message segmentation should be + provided. + +3.1.2. Transaction Identifier + + The Transaction Identifier in [5] does not distinguish between + replies from a request with "AckAll" and "NoSuccessAck". It also + does not provide any information about how to handle replies where + the Transaction ID doesn't match a Transaction ID from a previously + sent request. + + If multiple controllers are connected to a single switch and the + switch sends an event message with "ReturnReceipt" set to all of + them, there is no way for the switch to identify which controller the + receipt is coming from. + + The "ReturnReceipt" value should not be permitted for Events. + +3.2. Window Size + + The Switch Configuration Message defined in chapter 8.1 in [5] + defines a Window size to be used by the controller when sending + messages to the switch. It is not stated if this window should apply + to all messages or only to messages that will always generate a + reply. + + If messages that may not generate a reply should be counted against + the window a time-out period when they are to be removed from the + window should be defined. + + It is not defined if the window should be cleared when the adjacency + is lost and later recovered. + +3.3. Retransmission + + A retransmission policy with a well-designed exponential backoff + should be used if no reply is received for a message with "AckAll" + set. + + + + + +Khosravi, et al. Informational [Page 11] + +RFC 3604 Adding Optical Support to GSMPv3 October 2003 + + +3.4. Delete Branches Message + + The "Delete Branch Element" has a 4 bit Error field that should be + redefined to match the size of the "Failure Response Codes". + +3.5. Adjacency + + The chapter about how to handle a new adjacency and re-established + adjacencies should be clarified. + +3.5.1. Loss of Synchronization + + The switch must not reset the connection states if another adjacency + has already been established since this would destroy an already + valid state. + +4. Security Considerations + + The security of GSMP's TCP/IP control channel has been addressed in + [15]. Any potential remaining security considerations are not + addressed in this requirements document. + +5. Acknowledgements + + The list of authors provided with this document is a reduction of the + original list. Currently listed authors wish to acknowledge that a + substantial amount was also contributed to this work by: Avri Doria + and Kenneth Sundell + + The authors would like to acknowledge the careful review and comments + of Dimitri Papadimitriou, Torbjorn Hedqvist, Satoru Okamoto, and + Kohei Shiomoto. + +6. References + +6.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + +6.2. Informative References + + [2] Berger, L., Ed., "Generalized MPLS - Signaling Functional + Description", RFC 3471, January 2003. + + [3] Mannie, E., et al., "Generalized Multi-Protocol Label Switching + (GMPLS) Architecture", Work in Progress, May 2003. + + + + +Khosravi, et al. Informational [Page 12] + +RFC 3604 Adding Optical Support to GSMPv3 October 2003 + + + [4] ITU-T Recommendation, "Architecture for the Automatically + Switched Optical Network (ASON)", G.8080/Y.1304, January 2003 + + [5] Doria, A., Sundell, K., Hellstrand, F. and T. Worster, "General + Switch Management Protocol V3", RFC 3292, June 2002. + + [6] Sadler, J., Mack-Crane, B., "TDM Labels for GSMP", Work in + Progress, February 2001. + + [7] Rajagopalan, B., et al., "IP over Optical Networks: A + Framework", Work in Progress, September 2003. + + [8] ITU-T Recommendation, "Generic functional architecture of + transport networks", G.805, March 2000. + + [9] Braden, R., Clark, D. and S. Shenker, "Integrated Services in + the Internet Architecture: An Overview", RFC 1633, June 1994. + + [10] Wroclawski, J., "Specification of the Controlled-Load Network + Element Service", RFC 2211, September 1997. + + [11] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. + Weiss, _"An Architecture for Differentiated Services", RFC 2475, + December 1998. + + [12] C. Qiao, M. Yoo, "Choice, and Feature and Issues in Optical + Burst Switching", Optical Net. Mag., vol.1, No.2, Apr.2000, + pp.36-44. + + [13] Ilia Baldine, George N. Rouskas, Harry G. Perros, Dan + Stevension, "JumpStart: A Just-in-time Signaling Architecture + for WDM Burst-Switching Networks", IEEE Comm. Mag., Fab. 2002. + + [14] Sanjeev Verma, et al. "Optical burst switching: a viable + solution for terabit IP backbone", IEEE network, pp. 48-53, + Nov/Dec 2000. + + [15] Worster, T., Doria, A. and J. Buerkle, "GSMP Packet + Encapsulations for ATM, Ethernet and TCP", RFC 3293, June 2002. + + + + + + + + + + + + +Khosravi, et al. Informational [Page 13] + +RFC 3604 Adding Optical Support to GSMPv3 October 2003 + + +7. Authors' Addresses + + Hormuzd Khosravi + Intel + 2111 NE 25th Avenue + Hillsboro, OR 97124 USA + + Phone: +1 503 264 0334 + EMail: hormuzd.m.khosravi@intel.com + + + Georg Kullgren + Nortel Networks AB + S:t Eriksgatan 115 A + P.O. Box 6701 + SE-113 85 Stockholm Sweden + + EMail: geku@nortelnetworks.com + + + Jonathan Sadler + Tellabs Operations, Inc. + 1415 West Diehl Road + Naperville, IL 60563 + + Phone: +1 630-798-6182 + EMail: Jonathan.Sadler@tellabs.com + + + Stephen Shew + Nortel Networks + PO Box 3511 Station C + Ottawa, ON + K1Y 4H7 + + EMail: sdshew@nortelnetworks.com + + + Kohei Shiomoto + + EMail: Shiomoto.Kohei@lab.ntt.co.jp + + + + + + + + + + +Khosravi, et al. Informational [Page 14] + +RFC 3604 Adding Optical Support to GSMPv3 October 2003 + + + Atsushi Watanabe + Nippon Telegraph and Telephone Corporation + 807A 1-1 Hikari-no-oka, Yokosuka-shi + Kanagawa 239-0847, Japan + + EMail: atsushi@exa.onlab.ntt.co.jp + + + Satoru Okamoto + Nippon Telegraph and Telephone Corporation + 9-11 Midori-cho 3-chome, Musashino-shi + Tokyo 180-8585, Japan + + EMail: okamoto@exa.onlab.ntt.co.jp + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Khosravi, et al. Informational [Page 15] + +RFC 3604 Adding Optical Support to GSMPv3 October 2003 + + +8. Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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 assignees. + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Khosravi, et al. Informational [Page 16] + |