Signaling Extensions for Wavelength Switched Optical Networks
draft-ietf-ccamp-wson-signaling-04
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7689.
|
|
|---|---|---|---|
| Authors | Greg M. Bernstein , Sugang Xu , Young Lee , Giovanni Martinelli , Hiroaki Harai | ||
| Last updated | 2012-10-22 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 7689 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-ccamp-wson-signaling-04
Network Working Group G. Bernstein
Internet Draft Grotto Networking
Intended status: Standards Track Sugang Xu
NICT
Expires: April 2013 Y.Lee
Huawei
G. Martinelli
Cisco
Hiroaki Harai
NICT
October 22, 2012
Signaling Extensions for Wavelength Switched Optical Networks
draft-ietf-ccamp-wson-signaling-04.txt
Abstract
This memo provides extensions to Generalized Multi-Protocol Label
Switching (GMPLS) signaling for control of wavelength switched
optical networks (WSON). Such extensions are necessary in WSONs
under a number of conditions including: (a) when optional
processing, such as regeneration, must be configured to occur at
specific nodes along a path, (b) where equipment must be configured
to accept an optical signal with specific attributes, or (c) where
equipment must be configured to output an optical signal with
specific attributes. In addition this memo provides mechanisms to
support distributed wavelength assignment with bidirectional LSPs,
and choice in distributed wavelength assignment algorithms. These
extensions build on previous work for the control of lambda and
G.709 based networks.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
Expires April 22, 2013 [Page 1]
Internet-Draft WSON Signaling Extensions October 2012
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 22, 2007.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
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 [RFC2119].
Table of Contents
1. Introduction...................................................3
2. Terminology....................................................3
3. Requirements for WSON Signaling................................4
3.1. WSON Signal Characterization..............................4
3.2. Per LSP Network Element Processing Configuration..........5
3.3. Bi-Directional WSON LSPs..................................5
3.4. Distributed Wavelength Assignment Support.................6
3.5. Out of Scope..............................................6
4. WSON Signal Traffic Parameters, Attributes and Processing......6
4.1. Traffic Parameters for Optical Tributary Signals..........6
4.2. Signal Attributes and Processing..........................7
4.2.1. WSON Processing Object Encoding......................8
5. Bidirectional Lightpath Setup..................................8
6. RWA Related....................................................9
6.1. Wavelength Assignment Method Selection....................9
7. Security Considerations.......................................10
Bernstein et al. Expires April 22, 2013 [Page 2]
Internet-Draft WSON Signaling Extensions October 2012
8. IANA Considerations...........................................10
9. Acknowledgments...............................................10
10. References...................................................11
10.1. Normative References....................................11
10.2. Informative References..................................11
Author's Addresses...............................................14
Intellectual Property Statement..................................15
Disclaimer of Validity...........................................16
1. Introduction
This memo provides extensions to Generalized Multi-Protocol Label
Switching (GMPLS) signaling for control of wavelength switched
optical networks (WSON). Fundamental extensions are given to permit
simultaneous bi-directional wavelength assignment while more
advanced extensions are given to support the networks described in
[RFC6163] which feature connections requiring configuration of
input, output, and general signal processing capabilities at a node
along a LSP.
These extensions build on previous work for the control of lambda
and G.709 based networks.
2. Terminology
CWDM: Coarse Wavelength Division Multiplexing.
DWDM: Dense Wavelength Division Multiplexing.
FOADM: Fixed Optical Add/Drop Multiplexer.
ROADM: Reconfigurable Optical Add/Drop Multiplexer. A reduced port
count wavelength selective switching element featuring ingress and
egress line side ports as well as add/drop side ports.
RWA: Routing and Wavelength Assignment.
Wavelength Conversion/Converters: The process of converting an
information bearing optical signal centered at a given wavelength to
one with "equivalent" content centered at a different wavelength.
Wavelength conversion can be implemented via an optical-electronic-
optical (OEO) process or via a strictly optical process.
WDM: Wavelength Division Multiplexing.
Bernstein et al. Expires April 22, 2013 [Page 3]
Internet-Draft WSON Signaling Extensions October 2012
Wavelength Switched Optical Networks (WSON): WDM based optical
networks in which switching is performed selectively based on the
center wavelength of an optical signal.
AWG: Arrayed Waveguide Grating.
OXC: Optical Cross Connect.
Optical Transmitter: A device that has both a laser tuned on certain
wavelength and electronic components, which converts electronic
signals into optical signals.
Optical Responder: A device that has both optical and electronic
components. It detects optical signals and converts optical signals
into electronic signals.
Optical Transponder: A device that has both an optical transmitter
and an optical responder.
Optical End Node: The end of a wavelength (optical lambdas)
lightpath in the data plane. It may be equipped with some
optical/electronic devices such as wavelength
multiplexers/demultiplexer (e.g. AWG), optical transponder, etc.,
which are employed to transmit/terminate the optical signals for
data transmission.
3. Requirements for WSON Signaling
The following requirements for GMPLS based WSON signaling are in
addition to the functionality already provided by existing GMPLS
signaling mechanisms.
3.1. WSON Signal Characterization
WSON signaling MUST convey sufficient information characterizing the
signal to allow systems along the path to determine compatibility
and perform any required local configuration. Examples of such
systems include intermediate nodes (ROADMs, OXCs, Wavelength
converters, Regenerators, OEO Switches, etc...), links (WDM systems)
and end systems (detectors, demodulators, etc...). The details of
any local configuration processes are out of the scope of this
document.
From [RFC6163] we have the following list of WSON signal
characteristic information:
Bernstein et al. Expires April 22, 2013 [Page 4]
Internet-Draft WSON Signaling Extensions October 2012
List 1. WSON Signal Characteristics
1. Optical tributary signal class (modulation format).
2. FEC: whether forward error correction is used in the digital
stream and what type of error correcting code is used
3. Center frequency (wavelength)
4. Bit rate
5. G-PID: General Protocol Identifier for the information format
The first three items on this list can change as a WSON signal
traverses a network with regenerators, OEO switches, or wavelength
converters. These parameters are summarized in the Optical Interface
Class as defined in the [WSON-Info] and the assumption is that a
class always includes signal compatibility information.
An ability to control wavelength conversion already exists in GMPLS
signaling along with the ability to share client signal type
information (G-PID). In addition, bit rate is a standard GMPLS
signaling traffic parameter. It is referred to as Bandwidth Encoding
in [RFC3471].
3.2. Per LSP Network Element Processing Configuration
In addition to configuring a network element (NE) along an LSP to
input or output a signal with specific attributes, we may need to
signal the NE to perform specific processing, such as 3R
regeneration, on the signal at a particular NE. In [RFC6163] we
discussed three types of processing not currently covered by GMPLS:
(A) Regeneration (possibly different types)
(B) Fault and Performance Monitoring
(C) Attribute Conversion
The extensions here MUST provide for the configuration of these
types of processing at nodes along an LSP.
3.3. Bi-Directional WSON LSPs
WSON signaling MAY support LSP setup consistent with the wavelength
continuity constraint for bi-directional connections. The following
cases MAY be separately supported:
Bernstein et al. Expires April 22, 2013 [Page 5]
Internet-Draft WSON Signaling Extensions October 2012
(a) Where the same wavelength is used for both upstream and
downstream directions
(b) Where different wavelengths can be used for both upstream and
downstream directions.
This document will review current GMPLS bidirectional solutions
according to WSON case.
3.4. Distributed Wavelength Assignment Support
WSON signaling MAY support the selection of a specific distributed
wavelength assignment method.
This method is beneficial in cases of equipment failure, etc., where
fast provisioning used in quick recovery is critical to protect
carriers/users against system loss. This requires efficient
signaling which supports distributed wavelength assignment, in
particular when the centralized wavelength assignment capability is
not available.
As discussed in the [RFC6163] different computational approaches for
wavelength assignment are available. One method is the use of
distributed wavelength assignment. This feature would allow the
specification of a particular approach when more than one is
implemented in the systems along the path.
3.5. Out of Scope
This draft does not address signaling information related to optical
impairments.
4. WSON Signal Traffic Parameters, Attributes and Processing
As discussed in [RFC6163] single channel optical signals used in
WSONs are called "optical tributary signals" and come in a number of
classes characterized by modulation format and bit rate. Although
WSONs are fairly transparent to the signals they carry, to ensure
compatibility amongst various networks devices and end systems it
can be important to include key lightpath characteristics as traffic
parameters in signaling [RFC6163].
4.1. Traffic Parameters for Optical Tributary Signals
In [RFC3471] we see that the G-PID (client signal type) and bit rate
(byte rate) of the signals are defined as parameters and in
Bernstein et al. Expires April 22, 2013 [Page 6]
Internet-Draft WSON Signaling Extensions October 2012
[RFC3473] they are conveyed Generalized Label Request object and the
RSVP SENDER_TSPEC/FLOWSPEC objects respectively.
4.2. Signal Attributes and Processing
Section 3.2. gave the requirements for signaling to indicate to a
particular NE along an LSP what type of processing to perform on an
optical signal or how to configure that NE to accept or transmit an
optical signal with particular attributes.
One way of accomplishing this is via a new EXPLICIT_ROUTE subobject.
Reference [RFC3209] defines the EXPLICIT_ROUTE object (ERO) and a
number of subobjects, while reference [RFC5420] defines general
mechanisms for dealing with additional LSP attributes. Although
reference [RFC5420] defines a RECORD_ROUTE object (RRO) attributes
subobject, it does not define an ERO subobject for LSP attributes.
Regardless of the exact coding for the ERO subobject conveying the
input, output, or processing instructions. This new "processing"
subobject would follow a subobject containing the IP address, or the
interface identifier [RFC3477], associated with the link on which it
is to be used along with any label subobjects [RFC3473].
In regards to specific information required, the [WSON-Encode]
already provides all necessary definitions and encoding. In
particular the Resource block information sub-TLV which contains,
among others, a list of available Optical Interface Classes and
processing capabilities.
The WSON Signal Processing object is defined as an LSP_ATTRIBUTES
and extends the PATH message. It is defined as the following:
<WSON Processing> ::= <RBInformation>
Where:
<RBInformation> is the object defined in Section 5.1 of [WSON-
Encode].
This is the only sub-TLV available within the <WSON Processing>.
Only one <RBInformation> object MUST be present.
Bernstein et al. Expires April 22, 2013 [Page 7]
Internet-Draft WSON Signaling Extensions October 2012
4.2.1. WSON Processing Object Encoding
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: to be defined by IANA
Value: sub-TLVS according to section 4.1.
5. Bidirectional Lightpath Setup
With the wavelength continuity constraint in CI-incapable [RFC3471]
WSONs, where the nodes in the networks cannot support wavelength
conversion, the same wavelength on each link along a unidirectional
lightpath should be reserved. In addition to the wavelength
continuity constraint, requirement 3.3 gives us another constraint
on wavelength usage in data plane, in particular, it requires the
same wavelength to be used in both directions. [RFC6163] in section
6.1 reports on the implication to GMPLS signaling related to both
bi-directionality and Distributed Wavelengths Assignment.
Current GMPLS solution defines a bidirectional LSP (as defined by
[RFC3471]). The label distribution is based on Label_Set and
Upstream_Label objects. In case of specific constraints such as the
same wavelengths in both directions, it may require several
signaling attempts using information from the Acceptable_Label_Set
received from path error messages. Since this mechanism is currently
available and proven to work, no additional extensions are needed
for WSON. Potential optimizations are left for further studies.
The usage of <WSON Processing> object for the bidirectional case is
the same as per unidirectional. When an intermediate node uses
information from this object to instruct a node about wavelength
regeneration, the same information applies to both downstream and
upstream directions.
Bernstein et al. Expires April 22, 2013 [Page 8]
Internet-Draft WSON Signaling Extensions October 2012
Some implementations may prefer using two unidirectional LSPs. This
solution has been always available as per [RFC3209] however recent
work introduces the association concept [RFC4872] and [ASSOC-Info].
Recent transport evolutions [ASSOC-ext] provide a way to associate
two unidirectional LSPs as a bidirectional LSP. In line with this, a
small extension can make this approach work for the WSON case.
6. RWA Related
6.1. Wavelength Assignment Method Selection
Routing + Distributed wavelength assignment (R+DWA) is one of the
options defined by the [RFC6163]. The output from the routing
function will be a path but the wavelength will be selected on a
hop-by-hop basis.
Under this hypothesis the node initiating the signaling process
needs to declare its own wavelength availability (through a
label_set object). Each intermediate node may delete some labels due
to connectivity constraints or its own assignment policy. At the
end, the destination node has to make the final decision on the
wavelength assignment among the ones received through the signaling
process.
As discussed in [HZang00] a number of different wavelength
assignment algorithms maybe employed. In addition as discussed in
[RFC6163] the wavelength assignment can be either for a
unidirectional lightpath or for a bidirectional lightpath
constrained to use the same lambda in both directions.
A simple TLV could be used to indication wavelength assignment
directionality and wavelength assignment method. This would be
placed in an LSP_REQUIRED_ATTRIBUTES object per [RFC5420]. The use
of a TLV in the LSP required attributes object was pointed out in
[Xu].
[TO DO: The directionality stuff needs to be reconciled with the
earlier material]
Unique Wavelength: 0 same wavelength in both directions, 1 may use
different wavelengths [TBD: shall we use only 1 bit]
Bernstein et al. Expires April 22, 2013 [Page 9]
Internet-Draft WSON Signaling Extensions October 2012
Wavelength Assignment Method: 0 unspecified (any), 1 First-Fit, 2
Random, 3 Least-Loaded (multi-fiber). Others TBD.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unique WL | WA Method | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7. Security Considerations
This document has no requirement for a change to the security models
within GMPLS and associated protocols. That is the OSPF-TE, RSVP-TE,
and PCEP security models could be operated unchanged.
However satisfying the requirements for RWA using the existing
protocols may significantly affect the loading of those protocols.
This makes the operation of the network more vulnerable to denial of
service attacks. Therefore additional care maybe required to ensure
that the protocols are secure in the WSON environment.
Furthermore the additional information distributed in order to
address the RWA problem represents a disclosure of network
capabilities that an operator may wish to keep private.
Consideration should be given to securing this information.
8. IANA Considerations
TBD. Once finalized in our approach we will need identifiers for
such things and modulation types, modulation parameters, wavelength
assignment methods, etc...
9. Acknowledgments
Authors would like to thanks Lou Berger and Cyril Margaria for
comments and suggestions.
Bernstein et al. Expires April 22, 2013 [Page 10]
Internet-Draft WSON Signaling Extensions October 2012
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003.
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A.
Ayyangar, " Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2006.
[WSON-Encode] Bernstein G., Lee Y., Li D., and W. Imajuku, "Routing
and Wavelength Assignment Information Encoding for
Wavelength Switched Optical Networks", draft-ietf-ccamp-
rwa-wson-encode-18 (work in progress), September 2012.
10.2. Informative References
[WSON-CompOSPF] Y. Lee, G. Bernstein, "OSPF Enhancement for Signal
and Network Element Compatibility for Wavelength Switched
Optical Networks", work in progress: draft-lee-ccamp-wson-
signal-compatibility-OSPF.
Bernstein et al. Expires April 22, 2013 [Page 11]
Internet-Draft WSON Signaling Extensions October 2012
[RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS
and PCE Control of Wavelength Switched Optical Networks",
work in progress: draft-bernstein-ccamp-wavelength-
switched-03.txt, February 2008.
[WSON-Info] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and
Wavelength Assignment Information Model for Wavelength
Switched Optical Networks", work in progress: draft-ietf-
ccamp-rwa-info-16, September 2012.
[HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing
and wavelength assignment approaches for wavelength-routed
optical WDM networks", Optical Networks Magazine, January
2000.
[Xu] S. Xu, H. Harai, and D. King, "Extensions to GMPLS RSVP-TE
for Bidirectional Lightpath the Same Wavelength", work in
progress: draft-xu-rsvpte-bidir-wave-01, November 2007.
[Winzer06] Peter J. Winzer and Rene-Jean Essiambre, "Advanced
Optical Modulation Formats", Proceedings of the IEEE, vol.
94, no. 5, pp. 952-985, May 2006.
[G.959.1] ITU-T Recommendation G.959.1, Optical Transport Network
Physical Layer Interfaces, March 2006.
[G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM
applications: DWDM frequency grid, June 2002.
[G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM
applications: CWDM wavelength grid, December 2003.
[G.Sup43] ITU-T Series G Supplement 43, Transport of IEEE 10G base-R
in optical transport networks (OTN), November 2006.
[RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4427, March
2006.
[RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE
Extensions in Support of End-to-End Generalized Multi-
Protocol Label Switching (GMPLS) Recovery", RFC 4872,
[ASSOC-Info] Berger, L., Faucheur, F., and A. Narayanan, "Usage of
The RSVP Association Object", draft-ietf-ccamp-assoc-info-
00 (work in progress), October 2010.
Bernstein et al. Expires April 22, 2013 [Page 12]
Internet-Draft WSON Signaling Extensions October 2012
[ASSOC-Ext] Zhang, F., Jing, R., "RSVP-TE Extension to Establish
Associated Bidirectional LSP", draft-zhang-mpls-tp-rsvp-
te-ext-associated-lsp-03 (work in progress), February
2011.
Bernstein et al. Expires April 22, 2013 [Page 13]
Internet-Draft WSON Signaling Extensions October 2012
Author's Addresses
Greg M. Bernstein (editor)
Grotto Networking
Fremont California, USA
Phone: (510) 573-2237
Email: gregb@grotto-networking.com
Nicola Andriolli
Scuola Superiore Sant'Anna, Pisa, Italy
Email: nick@sssup.it
Alessio Giorgetti
Scuola Superiore Sant'Anna, Pisa, Italy
Email: a.giorgetti@sssup.it
Lin Guo
Key Laboratory of Optical Communication and Lightwave Technologies
Ministry of Education
P.O. Box 128, Beijing University of Posts and Telecommunications,
P.R.China
Email: guolintom@gmail.com
Hiroaki Harai
National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi, Koganei,
Tokyo, 184-8795 Japan
Phone: +81 42-327-5418
Email: harai@nict.go.jp
Yuefeng Ji
Key Laboratory of Optical Communication and Lightwave Technologies
Ministry of Education
P.O. Box 128, Beijing University of Posts and Telecommunications,
P.R.China
Email: jyf@bupt.edu.cn
Daniel King
Old Dog Consulting
Email: daniel@olddog.co.uk
Young Lee (editor)
Huawei Technologies
Bernstein et al. Expires April 22, 2013 [Page 14]
Internet-Draft WSON Signaling Extensions October 2012
1700 Alma Drive, Suite 100
Plano, TX 75075
USA
Phone: (972) 509-5599 (x2240)
Email: ylee@huawei.com
Sugang Xu
National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi, Koganei,
Tokyo, 184-8795 Japan
Phone: +81 42-327-6927
Email: xsg@nict.go.jp
Giovanni Martinelli
Cisco
Via Philips 12
20052 Monza, IT
Phone: +39 039-209-2044
Email: giomarti@cisco.com
Intellectual Property Statement
The IETF Trust 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 any IETF 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.
Copies of Intellectual Property 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
Bernstein et al. Expires April 22, 2013 [Page 15]
Internet-Draft WSON Signaling Extensions October 2012
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
Disclaimer of Validity
All IETF Documents and the information contained therein are
provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
THE IETF TRUST 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 THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bernstein et al. Expires April 22, 2013 [Page 16]