One document matched: draft-lee-pce-wson-routing-wavelength-01.txt
Differences from draft-lee-pce-wson-routing-wavelength-00.txt
Network Working Group Y. Lee
Internet Draft Huawei
Intended status: Standard Track
Expires: August 2008 G. Bernstein
Grotto Networking
February 18, 2008
PCEP Requirements and Extensions for WSON Routing and Wavelength
Assignment
draft-lee-pce-wson-routing-wavelength-01.txt
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
This Internet-Draft will expire on August 18, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This memo provides application-specific requirements and protocol
enhancements for the Path Computation Element communication Protocol
(PCEP) for the support of Wavelength Switched Optical Networks (WSON).
Lee & Bernstein Expires August 18, 2008 [Page 1]
Internet-Draft PCEP Extension for WSON February 2008
Lightpath provisioning in WSONs requires a routing and wavelength
assignment (RWA) process. From a path computation perspective,
wavelength assignment is the process of determining which wavelength
can be used on each hop of a path and forms an additional routing
constraint to optical light path computation. Different computational
architectures for the RWA process are given and the PCEP extensions
needed to support these architectures are defined.
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 RFC-2119 0.
Table of Contents
1. Introduction................................................3
2. Background: RWA Computation Architectures....................4
3. PCECP Requirements..........................................5
3.1. RWA Computation Options.................................5
3.2. Optimization Degree.....................................6
3.3. Wavelength Assignment and Wavelength Set Information.....7
3.4. Lightpath Route Parameters..............................7
3.5. Timeliness Characteristics of Lightpath.................7
3.6. Duration of Lightpath...................................8
3.7. Wavelength Selection Preference.........................8
4. Protocol Extensions for Support of WSON RWA..................9
4.1. RWA Computation Options.................................9
4.2. Lightpath Route Parameter TLV..........................10
4.3. Wavelength Selection Preferences.......................11
4.4. Wavelength Suggestion/Restriction TLV..................12
4.5. Error Indicator........................................13
4.6. NO-PATH Indicator......................................13
5. Manageability Considerations................................13
5.1. Control of Function and Policy.........................14
5.2. Information and Data Models, e.g. MIB module...........14
5.3. Liveness Detection and Monitoring......................14
5.4. Verifying Correct Operation............................14
5.5. Requirements on Other Protocols and Functional Components15
5.6. Impact on Network Operation............................15
6. Security Considerations.....................................15
7. IANA Considerations........................................15
Lee & Bernstein Expires August 18, 2008 [Page 2]
Internet-Draft PCEP Extension for WSON February 2008
8. Acknowledgments............................................15
9. References.................................................16
9.1. Normative References...................................16
9.2. Informative References.................................16
Authors' Addresses............................................17
Intellectual Property Statement................................17
Disclaimer of Validity........................................18
1. Introduction
[RFC4655] defines the PCE based Architecture and explains how a Path
Computation Element (PCE) may compute Label Switched Paths (LSP) in
Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and
Generalized MPLS (GMPLS) networks at the request of Path Computation
Clients (PCCs). A PCC is shown to be any network component that
makes such a request and may be for instance an Optical Switching
Element with a Wavelength Division Multiplexing (WDM) network. The
PCE, itself, can be located anywhere within the network, and may be
within an optical switching element, a Network Management System (NMS)
or Operational Support System (OSS), or may be an independent network
server.
The PCE communications Protocol (PCEP) is the communication protocol
used between PCC and PCE, and may also be used between cooperating
PCEs. [RFC4657] sets out the common protocol requirements for PCEP.
Additional application-specific requirements for PCEP are deferred to
separate documents.
This document provides a set of application-specific PCEP
requirements and protocol enhancements for support of path
computation in Wavelength Switched Optical Networks (WSON). WSON
refers to WDM based optical networks in which switching is performed
selectively based on the wavelength of an optical signal.
The path in WSON is referred to as a lightpath. A lightpath may span
multiple fiber links and the path should be assigned a wavelength for
each link. A transparent optical network is made up of optical
devices that can switch but not convert wavelengths. In a transparent
optical network, a lightpath operates on the same wavelength across
all fiber links that it traverses. In such case, the lightpath is
said to satisfy the wavelength-continuity constraint. Two lightpaths
that share a common fiber link should not be assigned the same
wavelength otherwise blocking will occur during lightpath
provisioning. Therefore, assigning the proper wavelength on a
Lee & Bernstein Expires August 18, 2008 [Page 3]
Internet-Draft PCEP Extension for WSON February 2008
lightpath is an essential requirement in the optical path computation
process.
On the other hand, when a switching node has the ability to perform
wavelength conversion the wavelength-continuity constraint can be
relaxed, and a lightpath may use different wavelengths on different
links along its route from origin to destination. It is, however, to
be noted that wavelength converters may be limited due to their high
cost, while the number of WDM channels that can be supported in a
fiber is also limited. As a WSON can be composed of network nodes
that cannot perform wavelength conversion, nodes with limited
wavelength conversion, and nodes with full wavelength conversion
abilities, wavelength assignment is an additional routing constraint
to be considered in all lightpath computation.
The remainder of this document uses terminology from [RFC4655].
2. Background: RWA Computation Architectures
The WSON framework [WSON-FRAME] document defines the following RWA
computation architectures.
o Combined RWA --- Both routing and wavelength assignment are
performed at a single computational entity. This choice assumes
that computational entity has sufficient WSON network link/nodal
and topology information to be able to compute RWA.
o Separate Routing and WA --- Separate entities perform routing and
wavelength assignment. The path(s) obtained from the routing
computational entity must be furnished to the entity performing
wavelength assignment.
o Routing with Distributed WA --- Routing is performed at a
computational entity while wavelength assignment is performed in a
distributed fashion across the nodes along the path.
For the Combined RWA architecture, there are two possible computing
entities: (i) the NE is the computational entity -- in this case,
there is no separate PCE as the NE assumes PCE function; (ii) a
separate PCE is the computational entity. This document is only
concerned with case (ii). In this case, the PCE should perform both
routing (R) and wavelength assignment (WA) upon request of the PCC.
Lee & Bernstein Expires August 18, 2008 [Page 4]
Internet-Draft PCEP Extension for WSON February 2008
For the Separate Routing and Wavelength architecture, there can be
two variations:
o A separate PCE will perform only wavelength assignment (WA) while
the NE performs the route calculation based on its local knowledge.
In this case, the NE should furnish the route list to the PCE so
that the PCE would be able to assign wavelength to the route.
o One PCE performs the routing (R) function while another PCE
performs the Wavelength Assignment (WA) function in a tandem
fashion. The fact that two PCEs are involved (one for Routing and
one for Wavelength Assignment (WA)) could be invisible to the
original PCC.
For the Routing with Distributed WA architecture, the PCE is only
responsible for routing (i.e., path computation), not for exact
wavelength assignment. The exact assignment of wavelengths would be
performed at the NEs along the path in a distributed fashion. However,
the PCE may choose to limit the wavelengths that can be used (i.e.,
by specifying a wavelength set to the NEs).
3. PCECP Requirements
This section provides the PCECP requirements to support WSON routing
and wavelength assignment (RWA) applications. The requirements
specified in this section are detailed requirements based on high-
level specification in [WSON-FRAME].
3.1. RWA Computation Options
The following RWA computation options should be conveyed in the PC
Request:
o The request is for both Routing and Wavelength Assignment (R+WA).
This case may arise when the NE is not capable of either route
calculation or wavelength assignment at the node level, or when a
more optimal RWA is desired.
o The request is for Routing (R) only. This case may arise when the
NE is not capable of route calculation at the node level while
wavelength assignment is done at the node level in a distributed
fashion.
Lee & Bernstein Expires August 18, 2008 [Page 5]
Internet-Draft PCEP Extension for WSON February 2008
o The request is for Wavelength Assignment (WA) only. This case may
arise when the NE is capable of route calculation at the node
level (e.g., via an IGP-TE) but with no wavelength information
is available at the node level, or when two PCEs work in tandem
with one performing the routing (R) function and another
wavelength assignment (WA). In either case, the calculated route
list at one computing entity should be supplied in the request
message to the other computing entity where WA is applied.
o The request is for Routing (R) with the suggested/restricted
wavelength set. This is a variation from the Routing only option.
With this option, the PCE computes the route and the candidate
wavelengths associated with the route. In this case, the exact
wavelength assignment is to be performed at the NE level.
The corresponding PC Reply message should include the following
information:
o An indicator that conveys the original request was for (i) WA only;
(ii) R+WA; (iii) R only; (iv) R with the suggested/restricted
wavelength set
o The route list and the recommended wavelengths to be used for the
route.
o In the case of failure to find a proper route or wavelengths
assigned to the route, proper reasons for the failure should be
conveyed: (i) route not found; (ii) wavelength not found (i.e.,
wavelength blocking); (iii) both route and wavelength not found.
3.2. Optimization Degree
The PC Request Message should indicate the degree of optimization
associated with lightpath computation.
o Concurrent Optimization: multiple lightpaths requested at once.
o Lightpath and backup lightpath requested at once.
o Sequential Optimization: single lightpath requested.
The PC Reply Message should include the original optimization degree
associated with the request when replying the path computation
results.
Lee & Bernstein Expires August 18, 2008 [Page 6]
Internet-Draft PCEP Extension for WSON February 2008
3.3. Wavelength Assignment and Wavelength Set Information
The PCE MUST specify the wavelength assignment and/or wavelength set
information in response to the wavelength assignment/wavelength set
Request made by the PCC in the PCReq message.
If the original request is either for both Routing and Wavelength
Assignment or for Wavelength Assignment only, the exact wavelength
assignment result can be conveyed to the PCC using the ERO object and
ERO Label subobject within the ERO. Note that this is not a new
requirement. [PCEP] allows this mechanism, which is defined as the
Label Set mechanism in [RFC3471].
If the original request is for Routing with wavelength
suggested/restricted wavelength set, then the Wavelength Set
information must be provided to the PCC.
3.4. Lightpath Route Parameters
The request MAY indicate the specific lightpath route parameters in
the PCReq message:
o Bidirectional Assignment of wavelengths for a bidirectional LSP
request. This means that the same wavelength should be assigned in
both directions on each hop.
o Simultaneous assignment of the same wavelength to primary and
backup paths.
The PCRep message should include the original lightpath route
parameters associated with the request when replying with the path
computation results.
3.5. Timeliness Characteristics of Lightpath
The request MAY indicate the specific timeliness of the computation
request for a lightpath. This will likely be related to the use to
which the lightpath will be put:
o Time Critical: this type of request is useful for those lightpath
establishment requests used for restoration of service or other
high priority real time services.
Lee & Bernstein Expires August 18, 2008 [Page 7]
Internet-Draft PCEP Extension for WSON February 2008
o Soft Time Bounds: this type of request is a more typical new
connection request. While expected to be responsive, there should
be more time to take into account network optimization.
o Scheduled: this type of request is useful when the requested
lightpath connections are not time critical (i.e., the request is
significantly ahead of their intended "in-service" time. It is to
be noted that we will not explicitly deal with scheduled case in
this document but the optimization can be handled via [PCE-GCO].
The reply should indicate the original timeliness characteristics of
the lightpath request with path computation results.
3.6. Duration of Lightpath
The request MAY indicate specific lightpath duration information
associated with the request. This may be useful to the PCE since it
is not worthwhile to optimize lightpaths with relatively short
duration as compared to pseudo-static paths.
3.7. Wavelength Selection Preference
The PC Request MAY indicate computation objective functions that
specify the Wavelength Selection Preference to which a path
computation request is applied.
The Wavelength Selection Preference to be supported at the minimum is:
o Random
o First Fit
o Most Used
o Least Loaded
o Don't care: default
Note that the objective functions to be supported for a single LSP
request are listed in [PCEP] and [PCE-OF] and that the objective
functions to be supported for a concurrent LSP request are listed in
[PCE-GCO] and [PCE-OF].
Lee & Bernstein Expires August 18, 2008 [Page 8]
Internet-Draft PCEP Extension for WSON February 2008
The PCRep should indicate which wavelength selection preference has
actually been applied.
4. Protocol Extensions for Support of WSON RWA
This section describes PCEP extension necessary to meet the
requirements set out in the previous section.
4.1. RWA Computation Options
The PCC has to include the RWA computation option in the PCReq
message in order to convey a particular computation option. To
support such indication a new flag, the RC flag, is defined in the RP
(Request Parameter) Object.
The RC flag is defined in the Flags field of the RP (Request
Parameter) object as follows. Bit number assignment to be confirmed
by IANA (see Section 8).
Bit Name Description Reference
10-11 RC-bits Routing Wavelength Computation This document
RC bits (Routing wavelength Computation bits - 2 bits):
o 11: Request is for both R (Routing) and Wavelength Assignment (WA).
o 01: Request is for Wavelength Assignment (WA) only.
o 10: Request is for Routing (R) with suggested/restricted
Wavelength Set
o 00: Request is for Routing (R) only.
When the RC bits are set to 11 in a PCReq message, the requesting PCC
requires the PCE to provide in the PCRep message the assigned
wavelength associated with the computed path. This request is for
both Routing (R) and Wavelength Assignment (WA).
When the RC bits are set to 01 in a PCReq message, the requesting PCC
requires the PCE only to provide wavelength assignment (WA). In such
case, the PCC must provide the already computed route (as indicated
Lee & Bernstein Expires August 18, 2008 [Page 9]
Internet-Draft PCEP Extension for WSON February 2008
by the ERO and the Bandwidth Object following the RP object) to which
the PCE would assign the wavelengths. Note that this option is to
fulfill one of the RWA computational architectures, namely, the
Separate Routing and WA option.
When the RC bits are set to 10, then the PCE is expected to provide
some suggestive or restrictive wavelength information associated with
the route.
When the RC bits are set to 11, 01, or 10, then additional parameters
associated with the requested lightpath SHOULD be provided in
optional Lightpath Route Parameter TLV (as specified in Section 3.4)
within the RP object. See Section 4.2 for the encoding of Lightpath
Route Parameter TLV.
The RP object in the PCRep message SHOULD properly indicate the
original request for the RWA Computation (RC) bit and I bit that have
actually been applied by the PCE. The actual route list and
wavelength assignment is to be found in the ERO within ERO Label
subobjects. ERO Label subobjects can be used to indicate the
wavelength to be used on particular links. Note that GMPLS signaling
[RFC3473] supports an explicit route object (ERO) and with ERO Label
subobjects.
4.2. Lightpath Route Parameter TLV
When the RC bit is set to 11, 01, or 10 in the RP object in a PCReq
message, then the following Lightpath Route Parameter TLV SHOULD be
included as part of the RP object within the PCReq message.
The format of the Lightpath Route Parameter TLV is as follows:
Lee & Bernstein Expires August 18, 2008 [Page 10]
Internet-Draft PCEP Extension for WSON February 2008
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|S| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type To be defined by IANA (suggested value = x)
Length 2 bits
Value I bit: 0 or 1
S bit: 0 or 1
Figure 1 The Lightpath Route Parameter TLV in the RP object in the
PCReq Message
I bit (Bidirectional Assignment of wavelengths - 1 bit):
o 0: Request is for bidirectional assignment of wavelengths
o 1: Request is for unidirectional assignment of wavelengths
S bit (Same Wavelength to primary and backup paths - 1 bit):
o 0: Request is for assignment of the same wavelength to primary and
backup paths.
o 1: Request is for assignment of the different wavelength to
primary and backup paths.
4.3. Wavelength Selection Preferences
When the RC (RWA Computation) flags in the RP object of a PCReq
indicate computing wavelength assignment, then the following
Wavelength Selection Preference TLV MAY be included in the RP object
as an optional TLV.
The format of the Wavelength Selection Preference TLV is as follows:
Lee & Bernstein Expires August 18, 2008 [Page 11]
Internet-Draft PCEP Extension for WSON February 2008
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength Selection Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type To be defined by IANA (suggested value = x)
Length 32 bits
Value Wavelength Selection Preference
Figure 2 The Wavelength Selection/Assignment Preferences TLV in
the RP object in the PCReq Message
Five wavelength selection preferences are defined in this document
and their identifier should be assigned by IANA (suggested value)
Function
Code Description
-------- ------------
1 Random
2 First Fit
3 Most Used
4 Least Loaded
5 Don't Care
The Wavelength Selection Preference TLV should also be included in
the RP object in the PCRep message to indicate which wavelength
selection preference has actually been applied by the PCE in its
wavelength assignment procedure.
4.4. Wavelength Suggestion/Restriction TLV
With the Routing with Distributed Wavelength Assignment option, the
PCRep should specify the wavelength set information in response to
the wavelength assignment/wavelength set Request made by the PCC in
the PCReq message if so requested by the setting of the RC bits in
the RP object in the PCReq message.
Lee & Bernstein Expires August 18, 2008 [Page 12]
Internet-Draft PCEP Extension for WSON February 2008
We refer to this information as wavelength restriction TLV.
The encoding of wavelength Suggestion/Restriction TLV is to be
provided in the next version.
4.5. Error Indicator
To indicate errors associated with the RWA request, a new Error-Type
(15) and subsequent error-values are defined as follows for inclusion
in the PCEP-ERROR object.
If a PCE receives a RWA computation request and the PCE is not
capable of RWA, the PCE MUST send a PCErr message with a PCEP ERROR
object (Error-Type=15) and an Error-Value (Error-Value=1). The
corresponding RWA computation request MUST be cancelled.
To indicate an error associated with policy violation, a new error
value "RWA not allowed" is added to the existing error code for
policy violation (Error-Type=6) as defined in [PCEP].
If a PCE receives a RWA computation request which is not compliant
with administrative privileges (i.e., the PCE policy does not support
RWA), the PCE MUST send a PCErr message with a PCEP-ERROR Object
(Error-Type=6) and an Error-Value (Error-Value=3). The corresponding
RWA computation MUST be cancelled.
4.6. NO-PATH Indicator
To communicate the reason(s) for not being able to find RWA
computation, the NO-PATH object MAY be used in the PCRep message. The
NO-PATH object is defined in [PCEP].
As defined in [PCEP], the NO-PATH object carries the NO-PATH_VECTOR
TLV which has a flags field. One new bit flag is defined in this
document to indicate RWA-specific computation failures as follows:
0x10: when set, the PCE indicates that no wavelength was found
associated with RWA computation in the PCRep message.
5. Manageability Considerations
Manageability of WSON Routing and Wavelength Assignment (RWA) with
PCE must address the following considerations:
Lee & Bernstein Expires August 18, 2008 [Page 13]
Internet-Draft PCEP Extension for WSON February 2008
5.1. Control of Function and Policy
In addition to the parameters already listed in Section 8.1 of [PCEP],
a PCEP implementation SHOULD allow configuring the following PCEP
session parameters on a PCC:
o The ability to send a WSON RWA request.
In addition to the parameters already listed in Section 8.1 of [PCEP],
a PCEP implementation SHOULD allow configuring the following PCEP
session parameters on a PCE:
o The support for WSON RWA.
o The maximum number of synchronized path requests associated with
WSON RWA per request message.
o A set of WSON RWA specific policies (authorized sender, request
rate limiter, etc).
These parameters may be configured as default parameters for any PCEP
session the PCEP speaker participates in, or may apply to a specific
session with a given PCEP peer or a specific group of sessions with a
specific group of PCEP peers.
5.2. Information and Data Models, e.g. MIB module
Extensions to the PCEP MIB module defined in [PCEP-MIB] should be
defined, so as to cover the WSON RWA information introduced in this
document. A future revision of this document will list the
information that should be added to the MIB module.
5.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already
listed in section 8.3 of [PCEP].
5.4. Verifying Correct Operation
Mechanisms defined in this document do not imply any new verification
requirements in addition to those already listed in section 8.4 of
[PCEP]
Lee & Bernstein Expires August 18, 2008 [Page 14]
Internet-Draft PCEP Extension for WSON February 2008
5.5. Requirements on Other Protocols and Functional Components
The PCE Discovery mechanisms ([ISIS PCED] and [OSPF PCED]) may be
used to advertise WSON RWA path computation capabilities to PCCs.
5.6. Impact on Network Operation
Mechanisms defined in this document do not imply any new network
operation requirements in addition to those already listed in section
8.6 of [PCEP].
6. Security Considerations
This document has no requirement for a change to the security models
within PCEP [PCEP]. However 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.
7. IANA Considerations
A future revision of this document will present requests to IANA for
codepoint allocation.
8. Acknowledgments
The authors would like to thank Adrian Farrel for many helpful
comments that greatly improved the contents of this draft.
This document was prepared using 2-Word-v2.0.template.dot.
Lee & Bernstein Expires August 18, 2008 [Page 15]
Internet-Draft PCEP Extension for WSON February 2008
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", RFC 4657,
September 2006.
[PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) communication Protocol (PCEP) - Version 1",
draft-ietf-pce-pcep, work in progress.
9.2. Informative References
[PCE-OF] Le Roux, JL., Vasseur, JP., and Y. Lee, "Objective Function
encoding in Path Computation Element communication and
discovery protocols", draft-ietf-pce-pce-of, work in
progress.
[PCE-GCO] Y. Lee, J.L. Le Roux, D. King, and E. Oki, "Path
Computation Element Communication Protocol (PCECP)
Requirements and Protocol Extensions In Support of Global
Concurrent Optimization", draft-ietf-pce-global-concurrent-
optimization, work in progress.
[WSON-FRAME] Bernstein, G. and Lee, Y. (Editors), and W. Imajuku,
"Framework for GMPLS and PCE Control of Wavelength Switched
Optical Networks", draft-bernstein-ccamp-wavelength-
switched, work in progress.
Lee & Bernstein Expires August 18, 2008 [Page 16]
Internet-Draft PCEP Extension for WSON February 2008
[ISIS-PCED] Le Roux, J. and JP. Vasseur, "IS-IS protocol extensions
for Path Computation Element (PCE) Discovery", draft-ietf-
pce-disco-proto-isis, work in progress.
[OSPF-PCED] Le Roux, J. and JP. Vasseur, "OSPF protocol extensions
for Path Computation Element (PCE) Discovery", draft-ietf-
pce-disco-proto-ospf, work in progress.
Authors' Addresses
Young Lee (Ed.)
Huawei Technologies
1700 Alma Drive, Suite 100
Plano, TX 75075, USA
Phone: (972) 509-5599 (x2240)
Email: ylee@huawei.com
Greg Bernstein (Ed.)
Grotto Networking
Fremont, CA, USA
Phone: (510) 573-2237
Email: gregb@grotto-networking.com
Intellectual Property Statement
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.
Lee & Bernstein Expires August 18, 2008 [Page 17]
Internet-Draft PCEP Extension for WSON February 2008
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lee & Bernstein Expires August 18, 2008 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-23 17:26:12 |