Internet DRAFT - draft-xu-rsvpte-bidir-wave

draft-xu-rsvpte-bidir-wave



Network Working Group                                         Sugang Xu
Internet-Draft                                            Hiroaki Harai
Intended status: Standards Track                                   NICT
Expires: May 2008                                           Daniel King
                                                          Aria Networks
                                                       November 12 2007


     Extensions to GMPLS RSVP-TE for Bidirectional Lightpath
                   with the Same Wavelength

                 draft-xu-rsvpte-bidir-wave-01

Status of This Memo

By submitting this Internet-Draft, each author represents that any 
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware 
will be disclosed, in accordance with Section 6 of 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.

The list of Internet-Draft Shadow Directories can be accessed at 
http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

For bidirectional lightpaths provisioning, in the case of optical nodes
that do not support wavelength conversion, it would be necessary to use
the same wavelength along the route on each direction. In certain 
optical network scenarios, the use of the same wavelength on both 
directions would be advantageous.  For instance, some ROADMs may 
add/drop the same wavelength simultaneously. In other cases, the users'
optical end nodes are equipped with fixed-wavelength transponders. 

This document describes extensions to RSVP-TE signaling for 
bidirectional wavelength lightpaths that require the same wavelength on
both directions. By using an LSP_ATTRIBUTES object defined in [RFC4420],
the extensions enable the new type lightpaths to support the low cost 
configuration at users' optical end nodes.



Xu et al.                   Expires May 2008              [Page 1]

Internet-Draft     draft-xu-rsvpte-bidir-wave-01.txt     November 2007

Table of Contents

1. Conventions Used in This Document................................2
2. Terminology......................................................2
3. Introduction and Problem Statement...............................3
3.1 Port-remapping Problem..........................................3
3.2 Port-remapping with OXC.........................................6
4. Avoiding Port-remapping Problem..................................7
4.1 Bidirectional Lightpath using Same Wavelength on Both Directions.7
4.2 Inefficient Alternate Solutions.................................7
4.2.1 Unidirectional Lightpaths with the Same Wavelength............7
4.2.2 Upstream Label Set and Label Set..............................7
5. Using LSP_ATTRIBUTES Object......................................8
6. Label Set Object and Bidirectional Lightpath.....................8
6.1 Procedure.......................................................8
7. Backward Compatibility Considerations............................9
8. Wavelength Assignment Issue..................................... 9
9. Link Bundling Issue.............................................10
10. IANA Considerations............................................10
11. Security Considerations........................................10
12. Acknowledgements...............................................10
13. Normative References...........................................10
14. Authors' Addresses.............................................10

1.  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].

2.  Terminology

The readers are assumed to be familiar with the terminology defined 
in [RFC3471], [RFC3473] and [RFC4420].

The term "node" in this document, when used in the context of the 
procedure description in section 6, refers to the GMPLS node which 
is the signaling controller in the control plane.

The term "receiver" in this document indicates a GMPLS node, which 
receives messages from its GMPLS neighbor nodes. 

The term "optical transmitter" in this document is a device that has
both a laser tuned on certain wavelength and electronic components,
which converts electronic signals into optical signals. 

The term "optical responder" in this document is a device that has 
both optical and electronic components. It detects optical signals 
and converts optical signals into electronic signals. 

The term "optical transponder" in this document is a device that has 
both an optical transmitter and an optical responder.

The term "optical end node" in this document is the end of a wavelength

Xu et al.                   Expires May 2008              [Page 2]

Internet-Draft     draft-xu-rsvpte-bidir-wave-01.txt     November 2007

(optical lambdas) lightpath in the data plane.  It may be equipped with
some optical/electronic devices such as wavelength 
multiplexers/demultiplexer (e.g. arrayed wavelength grating (AWG)), 
optical transponder, etc., which are employed to transmit/terminate the
optical signals for data transmission.

The term "wavelength-routed network" in this document is a network
that consists of transit nodes which may be equipped with wavelength
selective switching elements such as reconfigurable optical add/drop
multiplexer (ROADM) or optical cross-connect (OXC), and optical end
nodes at edges.  Wavelength lightpaths between optical end nodes can
be established across the network.

3. Introduction and Problem Statement

With the Lambda Switch (LSC) support defined in GMPLS [RFC3471] and 
RSVP-TE signaling [RFC3473], by properly configuring the wavelength 
selective switching elements such as ROADMs or OXCs at the transit 
nodes, both unidirectional and bidirectional wavelength (optical 
lambdas) lightpaths can be established in a wavelength-routed network.
To provide high-performance full-duplex transmission links between 
users' optical end nodes (e.g. computers, switches and routers, which 
are equipped with the necessary optical transmitters and responders) 
directly, bidirectional lightpaths should be established between users'
optical end nodes. 

This document considers the various scenarios where bidirectional 
lightpaths would be required for users' direct full-duplex end-end 
communications. By using the LSP_ATTRIBUTES object defined in [RFC4420],
new extensions to RSVP-TE signaling are introduced. These extensions
enable the lightpath to support the required configuration to enable the
same wavelength to be used on both directions between the users' optical
end nodes. 

The extensions in this document would be applied to various scenarios. 
For example, only a specific wavelength among the multiplexed 
wavelengths could be added/dropped to an optical end node. In another 
case, some type of ROADMs may add/drop the same wavelength 
simultaneously. In these cases, using the same wavelength on both 
directions is a solution. Another problem that takes into account users'
convenience, avoiding port-remapping, is stated as follows.

3.1 Port-remapping Problem

In the context of CI-incapable [RFC3471] wavelength-routed networks, 
where the nodes in the networks cannot support wavelength conversion, 
the same wavelength on each link along a unidirectional lightpath 
should be reserved.  According to the definition in [RFC3471], a 
bidirectional lightpath can be seen as a pair of unidirectional
lightpaths, which are provisioned along the same route simultaneously
by the RSVP-TE signaling with Upstream Label and Label Set Objects in
the messages [RFC3473]. 
 
A previously defined bidirectional lightpath does not 

Xu et al.                   Expires May 2008              [Page 3]

Internet-Draft     draft-xu-rsvpte-bidir-wave-01.txt     November 2007

necessarily require the same wavelength on both directions.  
In consequence, the selection of the upstream and downstream labels 
are independent.  That is to say, when establishing a bidirectional 
wavelength lightpath, the wavelengths on both directions selected 
using RSVP-TE may be different.  This may result in a 
wavelength-routed network specific port-remapping problem at both 
ends of the bidirectional lightpath.  This problem occurs in the 
following situations:

(1) Fixed wavelength multiplexer/demultiplexer like AWGs may be employed
at each node.  Each incoming and outgoing wavelength is with a dedicated
fixed port of AWG. For example, wavelength lambda 1 is on port 1, and 
wavelength lambda 2 is on port 2, and so on. See Fig.3.1.1.

   +--+
   |  |--->  lambda 1: port 1
-->|  |--->  lambda 2: port 2
   |  |--->  lambda 3: port 3
   +--+
A. AWG Demultiplexer case.
 
   +--+
   |  |<---  lambda 1: port 1
<--|  |<---  lambda 2: port 2
   |  |<---  lambda 3: port 3 
   +--+
B. AWG Multiplexer case.
   
Fig.3.1.1. The fixed wavelength-port mapping of AWG 
Multiplexer/Demultiplexer.

(2) Compared to a wavelength-tunable optical transponder array, low cost
fixed-tuned optical transponder array may be employed at the edge node.
In an optical transponder, the optical responder is bound with the 
transmitter.  Each of the optical transmitters and responders are 
physically connected to one port of AWG or OXC according to the 
configuration. See Fig.3.1.2.

   +--+               +----+
   |  |<---lambda 1---| T1 | 
<--|  |<---lambda 2---| T2 | 
   |  |<---lambda 3---| T3 | 
   +--+               +----+
AWG Multiplexer       optical transmitter array
A. The configuration with the optical transmitters connecting AWG. 

   +--+               +----+
   |  |---lambda 1--->| R1 | 
-->|  |---lambda 2--->| R2 | 
   |  |---lambda 3--->| R3 | 
   +--+               +----+
AWG Demultiplexer     optical responder array
B. One possible configuration with the optical responders connecting 
AWG.

Xu et al.                   Expires May 2008             [Page 4]

Internet-Draft     draft-xu-rsvpte-bidir-wave-01.txt     November 2007

   +--+    +-----+    +----+
   |  |--->|     |--->| R1 | 
-->|  |--->| OXC |--->| R2 | 
   |  |--->|     |--->| R3 | 
   +--+    +-----+    +----+
AWG Demultiplexer     optical responder array
C. One possible configuration with the optical responders connecting 
OXC.

Fig.3.1.2. The fixed optical transmitter/responder- AGW/OXC port 
mapping at the optical end nodes.

Consider a bidirectional lightpath with different wavelengths on two 
directions. The optical transmitter of which output wavelength is the 
same as the outgoing-wavelength (say lambda 1) is chosen first for 
using the lightpath. Then, the optical responder attached to that 
transmitter should be selected for receiving the incoming wavelength 
(say lambda 2). The responder generally can receive any of different 
wavelengths. Therefore, if another bidirectional lightpath is 
assigned the same outgoing wavelength (lambda 1) but with a different 
incoming wavelength (say lambda 3), the same transmitter and responder 
pair is selected. See Fig.3.1.3.

             +----+
<-lambda 1---| T1 |  
             +----+
A. Optical transmitter T1 sends optical signals on lambda 1.

             +----+
-lambda 2--->| R1 |  
             +----+  
B. Optical responder R1 receives optical signals on lambda 2 for one 
bidirectional lightpath.

             +----+
-lambda 3--->| R1 |  
             +----+  
C. Optical responder R1 can receive optical signals on lambda 3 for 
another bidirectional lightpath.

Fig.3.1.3. Transmitter sends optical signals on the fixed-tuned 
wavelength; the responder can receive data on different wavelengths.

However, the communication using the transponder and the 
bidirectional lightpath with different wavelengths will not succeed 
under the situations (1) and (2) mentioned above. Remember the fixed 
port mapping that each incoming wavelength is fixed on a unique port 
of AWG due to the situation (1), and the optical responder is also 
fixedly connected to a unique port of AWG or OXC due to the situation 
(2). Conversely, the incoming wavelength may change every 
lightpath (see lambda 2 and lambda 3 in the above case) for the same 
outgoing wavelength (lambda 1). The current incoming wavelength 
(lambda 3) is not on the port of AWG to which the optical responder 
connects originally (lambda 2), see Fig. 3.1.4.  To connect the 

Xu et al.                   Expires May 2008              [Page 5]

Internet-Draft     draft-xu-rsvpte-bidir-wave-01.txt     November 2007

optical responder to the proper port on which the incoming wavelength 
is, even in different outgoing wavelengths, a port-remapping process 
between the optical responder and AWG ports may be required.

   +--+               +----+
   |  |<---lambda 1---| T1 | 
<--|  |<---lambda 2---| T2 | 
   |  |<---lambda 3---| T3 | 
   +--+               +----+
   AWG Multiplexer   
A. Optical transmitter T1 sends optical signals on lambda 1.

   +--+
   |  |--            +----+
-->|  |--lambda2---->| R1 | 
   |  |--lambda3-X   +----+
   +--+   
AWG Demultiplexer    
B. Optical responder R1 cannot receive optical signals on lambda 3 
due to the fixed port mapping, in case of that R1 is physically 
connected to the port 2 of lambda 2 on AWG.

Fig. 3.1.4.  Port-remapping problem occurs due to the fixed 
port-mapping between the optical responder and AWG port.

3.2 Port-remapping with OXC

The port-remapping capability depends on the system configurations 
at users' optical end nodes.  For example, an OXC may be employed 
to switch the incoming wavelength from the port of AWG to the port 
which the optical responder is connected physically, see Fig. 3.2.1.  
However, equipping users' optical end nodes with OXCs introduces 
extra costs.  There exists a trade-off between port-remapping 
capability and cost/system complexity.

   +--+            +-------+    +----+
   |  |-lambda 1-->|    /--|--->| R1 | 
-->|  |-lambda 2-->|---/   |--->| R2 |
   |  |-lambda 3-->|  OXC  |--->| R3 |
   +--+            +-------+    +----+ 
AWG Demultiplexer
A. The optical responder R1 can receive the optical signals on lambda 
2.

      +--+            +-------+    +----+
      |  |-lambda 1-->|   /---|--->| R1 | 
   -->|  |-lambda 2-->|  /    |--->| R2 |
      |  |-lambda 3-->|-/ OXC |--->| R3 |
      +--+            +-------+    +----+ 
AWG Demultiplexer
B. The optical responder R1 can receive the optical signals on lambda 
3.

Fig.3.2.1. The port-remapping capability provided by OXC.

Xu et al.                   Expires May 2008              [Page 6]

Internet-Draft     draft-xu-rsvpte-bidir-wave-01.txt     November 2007

Users have various types of optical end node configurations to 
choose from.  Some configurations such as those equipped with OXCs might 
provide flexibility but could be costly and potentially complicated. 
Equally, while other configurations without OXCs might lack the 
flexibility they may be inexpensive and easy to use and maintain.  

4. Avoiding Port-remapping Problem

Which solution will be employed depends on the considerations of the 
flexibility and cost/complexity trade-off.  If users do not have 
port-remapping capability at optical end nodes, then it is 
necessary to avoid the port-remapping, and find a feasible approach 
to provide users full-duplex transmission capability with 
bidirectional lightpath.

4.1 Bidirectional Lightpath using Same Wavelength on Both Directions

A feasible approach is to establish a bidirectional lightpath with 
the same wavelength on both directions.  At the optical end node, 
fixed-tuned transponder array is connected to the proper ports of AWG 
according to the wavelength.  Optical transmitter and responder pair 
connecting the selected outgoing and incoming wavelength ports of AWG 
will be assigned to the bidirectional lightpath.  In this document, 
the bidirectional lightpath with the same wavelength on both 
directions is introduced as a complementary lightpath type.

4.2 Inefficient Alternate Solutions

4.2.1 Unidirectional Lightpaths with the Same Wavelength

Separately establishing two unidirectional lightpaths on different 
directions using the same wavelength between two optical end nodes might 
be an approach to support users' full-duplex transmission requirement.  
The same wavelength requirement could be achieved by sequentially 
scanning the wavelengths' availability on both directions.  Establish 
one-way lightpath first and verify the availability of the same 
wavelength on another lightpath.  If the wavelength is not available 
on both directions, release the former unidirectional lightpath, and 
repeat this process with a next wavelength, until an available 
wavelength is found on both directions.  However, this solution is 
inefficient because it might be time consuming during the scan process 
of the wavelength availability verification. 

4.2.2 Upstream Label Set and Label Set

Another approach is to extent the RSVP-TE signaling by defining an 
Upstream Label Set object, and to select the common free wavelengths 
along the upstream and downstream lightpaths.  Although it inherits 
the idea of Upstream Label from traditional bidirectional LSP, it is 
still not a neat solution and is inefficient.  

The simplest way is to only define an extension to the processing of 
Label Set [RFC3473], and leave the other processes untouched.  The 
issues related to this new functionality including an LSP_ATTRIBUTES 

Xu et al.                   Expires May 2008              [Page 7]

Internet-Draft     draft-xu-rsvpte-bidir-wave-01.txt     November 2007

object defined in [RFC4420] and the new procedure are described in 
the following sections. 

5. Using LSP_ATTRIBUTES Object

To trigger the new functionality at each GMPLS node, it is necessary 
to notify the receiver the new type lightpath request.  One 
multi-purpose flag/attribute parameter container object called 
LSP_ATTRIBUTES object and related mechanism defined in [RFC4420] meet 
this requirement. One bit in Attributes Flags TLV which indicates the 
new type lightpath, say, the bidirectional same wavelength lightpath 
will be present in an LSP_ATTRIBUTES object.  Please refer to 
[RFC4420] for detailed descriptions of the Flag and related issues.

6. Label Set Object and Bidirectional Lightpath

Considering the system configuration mentioned above, it is needed 
to add a new function into RSVP-TE to support bidirectional lightpath 
with same wavelength on both directions.

6.1 Procedure

The lightpath setup procedure is described below:

(1) Ingress node adds the new type lightpath indication in an 
LSP_ATTRIBUTES object.  It is propagated in the Path message in the 
same way as that of a Label Set object for downstream;

(2) On reception of a Path message containing both the new type 
lightpath indication in an LSP_ATTRIBUTES object and Label Set object, 
the receiver checks the local LSP database to see if the Label Set 
TLVs are acceptable on both directions jointly.  If there are 
acceptable wavelengths, then copy the values of them into new Label 
Set TLVs, and forward the Path message to the downstream node.  
Otherwise the Path message will be terminated, and a PathErr message 
with a "Routing problem/Label Set" indication will be generated;

(3) On reception of a Path message containing both such a new type 
lightpath indication in an LSP_ATTRIBUTES object and an Upstream Label 
object, the receiver MUST terminate the Path message using a PathErr 
message with Error Code "Unknown Attributes TLV" and Error Value set 
to the value of the new type lightpath TLV type code;

(4) On reception of a Path message containing both the new type 
lightpath indication in an LSP_ATTRIBUTES object and Label Set object, 
the egress node verifies whether the Label Set TLVs are acceptable, 
if one or more wavelengths are available on both directions, then any 
one available wavelength could be selected.  A Resv message is 
generated and propagated to upstream node;

(5) When a Resv message is received at an intermediate node, if it is a 
new type lightpath, the intermediate node allocates the label to 
interfaces on both directions and update internal database for this 
bidirectional same wavelength lightpath, then configures the local ROADM 

Xu et al.                   Expires May 2008              [Page 8]

Internet-Draft     draft-xu-rsvpte-bidir-wave-01.txt     November 2007

or OXC on both directions.

Except the procedure related to Label Set object, the other processes 
will be left untouched.

7. Backward Compatibility Considerations

Due to the introduction of new processing on Label Set object, it is 
required that each node in the lightpath is able to recognize the new 
type lightpath indication Flag carried by an LSP_ATTRIBUTES object, 
and deal with the new Label Set operation correctly.  It is noted that 
this new extension is not backward compatible.

According to the descriptions in [RFC4420], an LSR that does not 
recognize a TLV type code carried in this object MUST reject the Path 
message using a PathErr message with Error Code "Unknown Attributes 
TLV" and Error Value set to the value of the Attributes Flags TLV type 
code.

An LSR that does not recognize a bit set in the Attributes Flags TLV 
MUST reject the Path message using a PathErr message with Error Code 
"Unknown Attributes Bit" and Error Value set to the bit number of the 
new type lightpath Flag in the Attributes Flags.

The reader is referred to the detailed backward compatibility 
considerations expressed in [RFC4420].

8. Wavelength Assignment Issue

This signaling approach can be used for both combined routing and
wavelength assignment and separate routing and wavelength assignment
approaches, with and without Path Computation Element (PCE) support.
This signaling provides a unified signaling solution for different
scenarios.

a) Given a routing and wavelength assignment solution e.g. derived from
a PCE, an ingress node can put one wavelength label in Label set or a
Suggested label object to specify the wavelength. 

b) Given only routing solution e.g. from a PCE, an ingress node can set
one or more available wavelength label objects in Label set, and let the
egress node resolve the wavelength assignment in a distributed fashion.

c) Because this signaling solution can resolve wavelength assignment
problem itself, even without interaction with a PCE, by using an
explicit route e.g. manually, it is still possible to establish a
bidirectional lightpath. For example, a second lightpath is requested
between the same node pair of the previously established lightpath, e.g.
for quick recovery from failures, bidirectional signaling may negate a
PCE request. LSP set up time may also be reduced. Moreover, compared to
other crank back signaling approaches shown above, for distributed
wavelength assignment, this approach would have a lower blocking
probability and a shorter provisioning time.


Xu et al.                   Expires May 2008              [Page 9]

Internet-Draft     draft-xu-rsvpte-bidir-wave-01.txt     November 2007

9. Link Bundling Issue

PCE path computation problems may occur when computing bidirectional
lightpaths. In a GMPLS network where multiple component links are
aggregated into a link bundle and advertised as a single bidirectional
TE link, the Traffic Engineering Database (TED) may indicate the
availability of a particular lambda in both directions on the TE link.
However, it may actually be the case that the lambda is only available
in one direction on one component link, and the other direction is only
available on a different component link. In this scenario, creating an
end-to-end path that uses the same lambdas and the same component links
in both directions presents a PCE path computation problem. This
signaling can be used to verify the solution received from PCE. 

10. IANA Considerations 

One bit in Attributes Flags TLV which indicates the new type lightpath,
say, the bidirectional same wavelength lightpath will be present in an
LSP_ATTRIBUTES object. For example, one possible position in Attributes
Flags TLV is suggested to be the 9th bit. The actions for IANA are under
discussion, and will be added to the document in a later draft.

11. Security Considerations

This document adds new procedure related only to Label Set object at 
each node.  It does not introduce any new direct security issues, and 
the reader is referred to the security considerations expressed in 
[RFC3473] and [RFC4420].

12. Acknowledgements

The authors would like to thank to Adrian Farrel for helpful comments 
and feedback.

13. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate 
Requirement Levels", BCP 14, RFC 2119, March 1997. 

[RFC3471]  Berger, L. (Ed.), "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.

[RFC4420]  A. Farrel, et al., "Encoding of Attributes for 
Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) 
Establishment Using Resource ReserVation Protocol-Traffic 
Engineering (RSVP-TE) ", RFC 4420, February 2006

14. Authors' Addresses


Xu et al.                   Expires May 2008             [Page 10]

Internet-Draft     draft-xu-rsvpte-bidir-wave-01.txt     November 2007

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

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

Daniel King
Aria Networks
44/45 Market Place, Chippenham, SN15 3HU, United Kingdom

Phone: +44 7790 775187
Email: daniel.king@aria-networks.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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, 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   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.

Xu et al.                   Expires May 2008             [Page 11]

Internet-Draft     draft-xu-rsvpte-bidir-wave-01.txt     November 2007

   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.

Acknowledgements

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).







Xu et al.                   Expires May 2008              [Page 12]