|
Network Working Group Request for Comments: 4197 Category: Informational |
M. Riegel Siemens AG October 2005 |
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 © The Internet Society (2005).
This document defines the specific requirements for edge-to-edge emulation of circuits carrying Time Division Multiplexed (TDM) digital signals of the Plesiochronous Digital Hierarchy as well as the Synchronous Optical NETwork/Synchronous Digital Hierarchy over packet-switched networks. It is aligned to the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It makes references to the generic requirements for PWE3 where applicable and complements them by defining requirements originating from specifics of TDM circuits.
1. Introduction
1.1. TDM Circuits Belonging to the PDH Hierarchy
1.1.1. TDM Structure and Transport Modes
1.2. SONET/SDH Circuits
2. Motivation
3. Terminology
4. Reference Models
4.1. Generic PWE3 Models
4.2. Clock Recovery
4.3. Network Synchronization Reference Model
4.3.1. Synchronous Network Scenarios
4.3.2. Relative Network Scenario
4.3.3. Adaptive Network Scenario
5. Emulated Services
5.1. Structure-Agnostic Transport of Signals out of the
PDH Hierarchy
5.2. Structure-Aware Transport of Signals out of the
PDH Hierarchy
5.3. Structure-Aware Transport of SONET/SDH Circuits
6. Generic Requirements
6.1. Relevant Common PW Requirements
6.2. Common Circuit Payload Requirements
6.3. General Design Issues
7. Service-Specific Requirements
7.1. Connectivity
7.2. Network Synchronization
7.3. Robustness
7.3.1. Packet loss
7.3.2. Out-of-order delivery
7.4. CE Signaling
7.5. PSN Bandwidth Utilization
7.6. Packet Delay Variation
7.7. Compatibility with the Existing PSN Infrastructure
7.8. Congestion Control
7.9. Fault Detection and Handling
7.10. Performance Monitoring
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
10. Contributors Section
This document defines the specific requirements for edge-to-edge emulation of circuits carrying Time Division Multiplexed (TDM) digital signals of the Plesiochronous Digital Hierarchy (PDH) as well as the Synchronous Optical NETwork (SONET)/Synchronous Digital Hierarchy (SDH) over Packet-Switched Networks (PSN). It is aligned to the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3) as defined in [RFC3985]. It makes references to requirements in [RFC3916] where applicable and complements [RFC3916] by defining requirements originating from specifics of TDM circuits.
The term "TDM" will be used in this documents as a general descriptor for the synchronous bit streams belonging to either the PDH or the SONET/SDH hierarchies.
The bit rates traditionally used in various regions of the world are detailed in the normative reference [G.702]. For example, in North America, the T1 bit stream of 1.544 Mbps and the T3 bit stream of 44.736 Mbps are mandated, while in Europe, the E1 bit stream of 2.048 Mbps and the E3 bit stream of 34.368 Mbps are utilized.
Although TDM can be used to carry unstructured bit streams at the rates defined in [G.702], there is a standardized method of carrying bit streams in larger units called frames, each frame contains the same number of bits.
Related to the sampling frequency of voice traffic the bitrate is always a multiple of 8000, hence the T1 frame consists of 193 bits and the E1 frame of 256 bits. The number of bits in a frame is called the frame size.
The framing is imposed by introducing a periodic pattern into the bit stream to identify the boundaries of the frames (e.g., 1 framing bit per T1 frame, a sequence of 8 framing bits per E1 frame). The details of how these framing bits are generated and used are elucidated in [G.704], [G.706], and [G.751]. Unframed TDM has all bits available for payload.
Framed TDM is often used to multiplex multiple channels (e.g., voice channels each consisting of 8000 8-bit-samples per second) in a sequence of "timeslots" recurring in the same position in each frame. This multiplexing is called "channelized TDM" and introduces additional structure.
In some cases, framing also defines groups of consecutive frames called multiframes. Such grouping imposes an additional level of structure on the TDM bit-stream.
Unstructured TDM:
TDM that consists of a raw bit-stream of rate defined in [G.702],
with all bits available for payload.
Structured TDM:
TDM with one or more levels of structure delineation, including
frames, channelization, and multiframes (e.g., as defined in [G.704],
[G.751], and [T1.107]).
Structure-Agnostic Transport:
Transport of unstructured TDM, or of structured TDM when the
structure is deemed inconsequential from the transport point of view.
In structure-agnostic transport, any structural overhead that may be
present is transparently transported along with the payload data, and
the encapsulation provides no mechanisms for its location or
utilization.
Structure-Aware Transport:
Transport of structured TDM taking at least some level of the
structure into account. In structure-aware transport, there is no
guarantee that all bits of the TDM bit-stream will be transported
over the PSN network (specifically, the synchronization bits and
related overhead may be stripped at ingress and usually will be
regenerated at egress) or that transported bits will be situated in
the packet in their original order (but in this case, bit order is
usually recovered at egress; one known exception is loss of
multiframe synchronization between the TDM data and CAS bits
introduced by a digital cross-connect acting as a Native Service
Processing (NSP) block, see [TR-NWT-170]).
The term SONET refers to the North American Synchronous Optical NETwork as specified by [T1.105]. It is based on the concept of a Nx783 byte payload container repeated every 125us. This payload is referred to as an STS-1 SPE and may be concatenated into higher bandwidth circuits (e.g., STS-Nc) or sub-divided into lower bandwidth circuits (Virtual Tributaries). The higher bandwidth concatenated circuits can be used to carry anything from IP Packets to ATM cells to Digital Video Signals. Individual STS-1 SPEs are frequently used
to carry individual DS3 or E3 TDM circuits. When the 783 byte containers are sub-divided for lower rate payloads, they are frequently used to carry individual T1 or E1 TDM circuits.
The Synchronous Digital Hierarchy (SDH) is the international equivalent and enhancement of SONET and is specified by [G.707].
Both SONET and SDH include a substantial amount of transport overhead that is used for performance monitoring, fault isolation, and other maintenance functions along different types of optical or electrical spans. This also includes a pointer-based mechanism for carrying payloads asynchronously. In addition, the payload area includes dedicated overhead for end-to-end performance monitoring, fault isolation, and maintenance for the service being carried. If the main payload area is sub-divided into lower rate circuits (such as T1/E1), additional overhead is included for end-to-end monitoring of the individual T1/E1 circuits.
This document discusses the requirements for emulation of SONET/SDH services. These services include end-to-end emulation of the SONET payload (STS-1 SPE), emulation of concatenated payloads (STS-Nc SPE), as well as emulation of a variety of sub-STS-1 rate circuits jointly referred to as Virtual Tributaries (VT) and their SDH analogs.
[RFC3916] specifies common requirements for edge-to-edge emulation of circuits of various types. However, these requirements, as well as references in [RFC3985], do not cover specifics of PWs carrying TDM circuits.
The need for a specific document to complement [RFC3916] addressing of edge-to-edge emulation of TDM circuits arises from the following:
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 [RFC2119].
The terms defined in [RFC3985], Section 1.4 are used consistently. However some terms and acronyms are used in conjunction with the TDM services. In particular:
TDM networks employ Channel-Associated Signaling (CAS) or Common Channel Signaling (CCS) to supervise and advertise status of telephony applications, provide alerts to these applications (as to requests to connect or disconnect), and to transfer routing and addressing information. These signals must be reliably transported over the PSNs for the telephony end-systems to function properly.
CAS (Channel-Associated Signaling)
CAS is carried in the same T1 or E1 frame as the voice signals,
but not in the speech band. Since CAS signaling may be
transferred at a rate slower than the TDM traffic in a timeslot,
one need not update all the CAS bits in every TDM frame. Hence,
CAS systems cycle through all the signaling bits only after some
number of TDM frames, which defines a new structure known as a
multiframe or superframe. Common multiframes are 12, 16, or 24
frames in length, corresponding to 1.5, 2, and 3 milliseconds in
duration.
CCS (Common Channel Signaling)
CCS signaling uses a separate digital channel to carry
asynchronous messages pertaining to the state of telephony
applications over related TDM timeslots of a TDM trunk. This
channel may be physically situated in one or more adjacent
timeslots of the same TDM trunk (trunk associated CCS) or may be
transported over an entirely separate network.
CCS is typically HDLC-based, with idle codes or keep-alive messages being sent until a signaling event (e.g., on-hook or off-hook) occurs. Examples of HDLC-based CCS systems are SS7 [Q.700] and ISDN PRI signaling [Q.931].
Note: For the TDM network, we use the terms "jitter" and "wander" as defined in [G.810] to describe short- and long-term variance of the significant instants of the digital signal, while for the PSN we use the term packet delay variation (PDV) (see [RFC3393]).
Generic models that have been defined in [RFC3985] in sections
- 4.1 (Network Reference Model), - 4.2 (PWE3 Pre-processing), - 4.3 (Maintenance Reference Model), - 4.4 (Protocol Stack Reference Model) and - 4.5 (Pre-processing Extension to Protocol Stack Reference Model).
They are fully applicable for the purposes of this document without modification.
All the services considered in this document represent special cases of the Bit-stream and Structured bit-stream payload type defined in Section 3.3 of [RFC3985].
Clock recovery is extraction of the transmission bit timing information from the delivered packet stream. Extraction of this information from a highly jittered source, such as a packet stream, may be a complex task.
Figure 1 shows a generic network synchronization reference model.
+---------------+ +---------------+
| PE1 | | PE2 |
K | +--+ | | +--+ | G
| | | J| | | | H| | |
v | v | | | v | | v
+---+ | +-+ +-+ +-+ | +--+ +--+ | +-+ +-+ +-+ | +---+
| | | |P| |D| |P| | | | | | | |P| |E| |P| | | |
| |<===|h|<:|e|<:|h|<:::| |<::| |<:::|h|<:|n|<=|h|<===| |
| | | |y| |c| |y| | | | | | | |y| |c| |y| | | |
| C | | +-+ +-+ +-+ | | | | | | +-+ +-+ +-+ | | C |
| E | | | |S1| |S2| | | | E |
| 1 | | +-+ +-+ +-+ | | | | | | +-+ +-+ +-+ | | 2 |
| | | |P| |E| |P| | | | | | | |P| |D| |P| | | |
| |===>|h|=>|n|:>|h|:::>| |::>| |:::>|h|:>|e|=>|h|===>| |
| | | |y| |c| |y| | | | | | | |y| |c| |y| | | |
+---+ | +-+ +-+ +-+ | +--+ +--+ | +-+ +-+ +-+ | +---+
^ ^ | | ^ | | | ^ | ^ ^
| | | |B | |<------+------>| | | | | |
| A | +--+ | | | +--+-E | F |
| +---------------+ +-+ +---------------+ |
| ^ |I| ^ |
| | +-+ | |
| C D |
+-----------------------------L-----------------------------+
Figure 1: The Network Synchronization Reference Model
The following notation is used in Figure 1:
CE1, CE2
Customer edge devices terminating TDM circuits to be emulated.
PE1, PE2
Provider edge devices adapting these end services to PW.
S1, S2
Provider core routers.
Phy
Physical interface terminating the TDM circuit.
Enc
PSN-bound interface of the PW, where the encapsulation takes
place.
Dec
CE-bound interface of the PW, where the decapsulation takes place.
It contains a compensation buffer (also known as the "jitter
buffer") of limited size.
"==>"
TDM attachment circuits.
"::>"
PW providing edge-to-edge emulation for the TDM circuit.
The characters "A" - "L" denote various clocks:
"A"
The clock used by CE1 for transmission of the TDM attachment
circuit towards CE1.
"B"
The clock recovered by PE1 from the incoming TDM attachment
circuit. "A" and "B" always have the same frequency.
"G"
The clock used by CE2 for transmission of the TDM attachment
circuit towards CE2.
"H"
The clock recovered by PE2 from the incoming TDM attachment
circuit. "G" and "H" always have the same frequency.
"C", "D"
Local oscillators available to PE1 and PE2, respectively.
"E"
Clock used by PE2 to transmit the TDM attachment service circuit
to CE2 (the recovered clock).
"F"
Clock recovered by CE2 from the incoming TDM attachment service
("E and "F" have the same frequency).
"I"
If the clock exists, it is the common network reference clock
available to PE1 and PE2.
"J"
Clock used by PE1 to transmit the TDM attachment service circuit
to CE1 (the recovered clock).
"K"
Clock recovered by CE1 from the incoming TDM attachment service
("J" and "K" have the same frequency).
"L"
If it exists, it is the common reference clock of CE1 and CE2.
Note that different pairs of CE devices may use different common
reference clocks.
A requirement of edge-to-edge emulation of a TDM circuit is that clock "B" and "E", as well as clock "H" and "J", are of the same frequency. The most appropriate method will depend on the network synchronization scheme.
The following groups of synchronization scenarios can be considered:
Depending on which part of the network is synchronized by a common clock, there are two scenarios:
Figure 2 is an adapted version of the generic network reference model, and presents the PE synchronized network scenario.
The common network reference clock "I" is available to all the PE devices, and local oscillators "C" and "D" are locked to "I":
+-----+ +-----+
+-----+ | |- - -|=================|- - -| | +-----+
| /-- |<---------|............PW1..............|<---------| <-\ |
|| CE | | | PE1 | | PE2 | | |CE2 ||
| \-> |--------->|............PW2..............|--------->| --/ |
+-----+ | |- - -|=================|- - -| | +-----+
+-----+ +-----+
^ ^
|C |D
+-----------+-----------+
|
+-+
|I|
+-+
Figure 2: PE Synchronized Scenario
Figure 3 is an adapted version of the generic network reference model, and presents the CE synchronized network scenario.
The common network reference clock "L" is available to all the CE devices, and local oscillators "A" and "G" are locked to "L":
+-----+ +-----+
+-----+ | |- - -|=================|- - -| | +-----+
| |<---------|............PW1..............|<---------| |
| CE1 | | | PE1 | | PE2 | | | CE2 |
| |--------->|............PW2..............|--------->| |
+-----+ | |- - -|=================|- - -| | +-----+
^ +-----+ +-----+ ^
|A G|
+----------------------------+------------------------------+
|
+-+
|L|
+-+
Figure 3: CE Synchronized Scenario
No timing information has to be transferred in these cases.
In this case, each CE uses its own transmission clock source that must be carried across the PSN and recovered by the remote PE, respectively. The common PE clock "I" can be used as reference for this purpose.
Figure 4 shows the relative network scenario.
The common network reference clock "I" is available to all the PE devices, and local oscillators "C" and "D" are locked to "I":
In a slight modification of this scenario, one (but not both!) of the CE devices may use its receive clock as its transmission clock (i.e., use loop timing).
|G
+-----+ +-----+ v
+-----+ | |- - -|=================|- - -| | +-----+
| |<---------|............PW1..............|<---------| |
| CE1 | | | PE1 | | PE2 | | | CE2 |
| |--------->|............PW2..............|--------->| |
+-----+ | |- - -|=================|- - -| | +-----+
^ +-----+<-------+------->+-----+
|A |
+-+
|I|
+-+
Figure 4: Relative Network Scenario Timing
In this case, timing information (the difference between the common reference clock "I" and the incoming clock "A") MUST be explicitly transferred from the ingress PE to the egress PE.
The adaptive scenario is characterized by:
Figure 5 presents the adaptive network scenario.
|J |G
v |
+-----+ +-----+ v
+-----+ | |- - -|=================|- - -| | +-----+
| |<---------|............PW1..............|<---------| |
| CE1 | | | PE1 | | PE2 | | | CE2 |
| |--------->|............PW2..............|--------->| |
+-----+ | |- - -|=================|- - -| | +-----+
^ +-----+ +-----+
| ^
A| E|
Figure 5: Adaptive Scenario
Synchronizing clocks "A" and "E" in this scenario is more difficult than it is in the other scenarios.
Note that the tolerance between clocks "A" and "E" must be small enough to ensure that the jitter buffer does not overflow or underflow.
In this case, timing information MAY be explicitly transferred from the ingress PE to the egress PE, e.g., by RTP.
This section defines requirements for the payload and encapsulation layers for edge-to-edge emulation of TDM services with bit-stream payload as well as structured bit-stream payload.
Wherever possible, the requirements specified in this document SHOULD be satisfied by appropriate arrangements of the encapsulation layer only. The (rare) cases when the requirements apply to both the encapsulation and payload layers (or even to the payload layer only) will be explicitly noted.
The service-specific encapsulation layer for edge-to-edge emulation comprises the following services over a PSN.
Structure-agnostic transport is considered for the following signals:
Structure-aware transport is considered for the following signals:
Structure-aware transport is considered for the following SONET/SDH circuits:
Note: There is no requirement for the structure-agnostic transport of SONET/SDH. For this case, it would seem that structure must be taken into account.
The encapsulation and payload layers MUST conform to the common PW requirements defined in [RFC3916]:
Fragmentation indications MAY be used for structure-aware transport when the structures in question either exceed desired packetization delay or exceed Path MTU between the pair of PEs.
The following requirement listed in [RFC3916] is not applicable to emulation of TDM services:
Structure-agnostic transport treats TDM circuits as belonging to the 'Bit-stream' payload type defined in [RFC3985].
Structure-aware transport treats these circuits as belonging to the "Structured bit-stream" payload type defined in [RFC3985].
Accordingly, the encapsulation layer MUST provide the common
Sequencing service and SHOULD provide Timing information
(Synchronization services) when required (see Section 4.3 above).
Note: Length service MAY be provided by the encapsulation layer, but is not required.
The combination of payload and encapsulation layers SHOULD comply with the general design principles of the Internet protocols as presented in Section 3 of [RFC1958] and [RFC3985].
If necessary, the payload layer MAY use some forms of adaptation of the native TDM payload in order to achieve specific, well-documented design objectives. In these cases, standard adaptation techniques SHOULD be used.
The robustness of the emulated service depends not only upon the edge-to-edge emulation protocol, but also upon proper implementation of the following procedures.
Edge-to-edge emulation of TDM circuits MAY assume very low probability of packet loss between ingress and egress PE. In particular, no retransmission mechanisms are required.
In order to minimize the effect of lost packets on the egress service, the encapsulation layer SHOULD:
The encapsulation layer MUST provide the necessary mechanisms to guarantee ordered delivery of packets carrying the TDM data over the PSN. Packets that have arrived out-of-order:
Out-of-order packets that cannot be reordered MUST be treated as lost.
Unstructured TDM circuits would not usually require any special mechanism for carrying CE signaling as this would be carried as part of the emulated service.
Some CE applications using structured TDM circuits (e.g., telephony) require specific signaling that conveys the changes of state of these applications relative to the TDM data.
The encapsulation layer SHOULD support signaling of state of CE applications for the relevant circuits providing for:
CE signaling that is used for maintenance purposes (loopback commands, performance monitoring data retrieval, etc.) SHOULD use the generic PWE3 maintenance protocol.
The compensation buffer used by the CE-bound IWF increases latency to the emulated circuit. Additional delays introduced by this buffer SHOULD NOT exceed the packet delay variation observed in the PSN.
If used, dynamic suppression of temporarily unused channels MUST NOT violate the integrity of the structures delivered over the PW.
The encapsulation layer SHOULD provide for the ability to compensate for packet delay variation, while maintaining jitter and wander of the egress end service clock with tolerances specified in the normative references.
The encapsulation layer MAY provide for run-time adaptation of delay introduced by the jitter buffer if the packet delay variation varies with time. Such an adaptation MAY introduce a low level of errors (within the limits tolerated by the application) but SHOULD NOT introduce additional wander of the egress end service clock.
The combination of encapsulation and PSN tunnel layers used for edge- to-edge emulation of TDM circuits SHOULD be compatible with existing PSN infrastructures. In particular, compatibility with the mechanisms of header compression over links where capacity is at a premium SHOULD be provided.
TDM circuits run at a constant rate, and hence offer constant traffic loads to the PSN. The rate varying mechanism that TCP uses to match the demand to the network congestion state is, therefore, not applicable.
The ability to shut down a TDM PW when congestion has been detected MUST be provided.
Precautions should be taken to avoid situations wherein multiple TDM PWs are simultaneously shut down or re-established, because this leads to PSN instability.
Further congestion considerations are discussed in chapter 6.5 of [RFC3985].
The encapsulation layer for edge-to-edge emulation of TDM services SHOULD, separately or in conjunction with the lower layers of the PWE3 stack, provide for detection, handling, and reporting of the following defects:
The encapsulation layer for edge-to-edge emulation of TDM services SHOULD provide for collection of performance monitoring (PM) data that is compatible with the parameters defined for 'classic', TDM-based carriers of these services. The applicability of [G.826] is left for further study.
The security considerations in [RFC3916] are fully applicable to the emulation of TDM services. In addition, TDM services are sensitive to packet delay variation [Section 7.6], and need to be protected from this method of attack.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for
Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916,
September 2004.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005.
[G.702] ITU-T Recommendation G.702 (11/88) - Digital hierarchy
bit rates
[G.704] ITU-T Recommendation G.704 (10/98) - Synchronous frame
structures used at 1544, 6312, 2048, 8448 and 44 736
Kbit/s hierarchical levels
[G.706] ITU-T Recommendation G.706 (04/91) - Frame alignment and
cyclic redundancy check (CRC) procedures relating to
basic frame structures defined in Recommendation G.704
[G.707] ITU-T Recommendation G.707 (10/00) - Network node
interface for the synchronous digital hierarchy (SDH)
[G.751] ITU-T Recommendation G.751 (11/88) - Digital multiplex
equipments operating at the third order bit rate of 34
368 Kbit/s and the fourth order bit rate of 139 264
Kbit/s and using positive justification
[G.810] ITU-T Recommendation G.810 (08/96) - Definitions and
terminology for synchronization networks
[G.826] ITU-T Recommendation G.826 (02/99) - Error performance
parameters and objectives for international, constant
bit rate digital paths at or above the primary rate
[Q.700] ITU-T Recommendation Q.700 (03/93) - Introduction to
CCITT Signalling System No. 7
[Q.931] ITU-T Recommendation Q.931 (05/98) - ISDN user-network
interface layer 3 specification for basic call control
[RFC1958] Carpenter, B., "Architectural Principles of the
Internet", RFC 1958, June 1996.
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of
RTP Payload Format Specifications", BCP 36, RFC 2736,
December 1999.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay
Variation Metric for IP Performance Metrics (IPPM)", RFC
3393, November 2002.
[T1.105] ANSI T1.105 - 2001 Synchronous Optical Network (SONET) -
Basic Description including Multiplex Structure, Rates,
and Formats, May 2001
[T1.107] ANSI T1.107 - 1995. Digital Hierarchy - Format
Specification
[TR-NWT-170] Digital Cross Connect Systems - Generic Requirements and Objectives, Bellcore, TR-NWT-170, January 1993
The following have contributed to this document:
Sasha Vainshtein
Axerra Networks
EMail: sasha@axerra.com
Yaakov Stein
RAD Data Communication
EMail: yaakov_s@rad.com
Prayson Pate
Overture Networks, Inc.
EMail: prayson.pate@overturenetworks.com
Ron Cohen
Lycium Networks
EMail: ronc@lyciumnetworks.com
Tim Frost
Zarlink Semiconductor
EMail: tim.frost@zarlink.com
Maximilian Riegel
Siemens AG
St-Martin-Str 76
Munich 81541
Germany
Phone: +49-89-636-75194
EMail: maximilian.riegel@siemens.com
Copyright © The Internet Society (2005).
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.
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.
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 ietf- ipr@ietf.org.
Funding for the RFC Editor function is currently provided by the Internet Society.