GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3604

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:
  1. Digital Carrier Hierarchy (e.g., DS-1, E1)
  2. SONET and SDH Hierarchy (e.g., OC-3, STM-1, VT1.5, VC-12)
  3. Plesiochronous Data Hierarchy (PDH) labels [6]
  4. OTN G.709 labels
  5. Lambdas
  6. 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]:
  1. wavelengths available per interface
  2. bit rate per wavelength
  3. 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:
  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3604.txt · Last modified: 2003/10/03 18:55 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki