|
Dear CCAMPers,
We just posted a new I-D:
draft-zhang-ccamp-rwa-wson-routing-ospf-00.txt.
Following the work on the RWA problem in the existing
CCAMP drafts, and working with the protocol-independent encodings defined
in draft-ietf-ccamp-rwa-wson-encode, we have started work on OSPF
extensions. This work is at an early stage and we expect to revise the
document over the next months.
Any comments are welcome.
The following is the abstract of this new I-D, please
check out the attachment for details. =========================================================================
Abstract
Wavelength switched optical networks (WSONs) are based on Wavelength Division Multiplexing (WDM) in which user traffic is carried by data channels of different optical wavelengths. In traditional WDM Networks, each wavelength path is statically configured. With the deployment of Reconfigurable Optical Add-Drop Multiplexers (ROADMs), photonic cross-connects (PXCs), and tunable laser, WSONs have become more dynamic, and operators can flexibly set up wavelength paths to carry user traffic. In WSONs where there are no or a limited number of switches capable of wavelength conversion paths must be set up subject to the wavelength continuity" constraint. This leads to a path computation problem known as routing and wavelength assignment (RWA). In order to perform such computations, it is necessary to collect information about the available wavelengths within the network. This document describes OSPF routing protocols extensions to support Wavelength Switched Optical Networks (WSON) under the control of Generalized MPLS (GMPLS). Thanks Fatai Advanced Technology Department Wireline Networking Business Unit Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935
|
Network work group Fatai Zhang
Internet Draft Huawei
Intended status: Standards Track G. Bernstein
Expires: September 2009 Grotto Networking
Young Lee
Dan Li
Jianrui Han
Huawei
March 02, 2009
OSPF Extensions in Support of Routing and Wavelength
Assignment (RWA) in Wavelength Switched Optical Networks (WSONs)
draft-zhang-ccamp-rwa-wson-routing-ospf-00.txt
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.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 02, 2009.
Abstract
Wavelength switched optical networks (WSONs) are based on Wavelength
Division Multiplexing (WDM) in which user traffic is carried by data
channels of different optical wavelengths. In traditional WDM
Networks, each wavelength path is statically configured. With the
<Zhang> Expires September 2, 2009 [Page 1]
Internet-Draft OSPF Extensions for WSON March 2009
deployment of Reconfigurable Optical Add-Drop Multiplexers (ROADMs),
photonic cross-connects (PXCs), and tunable laser, WSONs have become
more dynamic, and operators can flexibly set up wavelength paths to
carry user traffic.
In WSONs where there are no or a limited number of switches capable
of wavelength conversion paths must be set up subject to the
"wavelength continuity" constraint. This leads to a path computation
problem known as routing and wavelength assignment (RWA). In order to
perform such computations, it is necessary to collect information
about the available wavelengths within the network.
This document describes OSPF routing protocols extensions to support
Wavelength Switched Optical Networks (WSON) under the control of
Generalized MPLS (GMPLS).
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 [RFC2119].
Table of Contents
1. Introduction.................................................3
2. Node Information.............................................3
2.1. Connectivity Matrix.....................................4
2.1.1. Link Set...........................................5
2.2. Wavelength Converter Pool Information...................7
3. Link Information.............................................7
3.1. WSON Port Wavelength Restrictions.......................8
3.2. Wavelength Availability Information.....................9
3.3. Shared Backup Wavelengths..............................11
4. Procedures for Routing Flooding.............................11
5. Security Considerations.....................................12
6. IANA Considerations.........................................12
6.1. Node Information.......................................12
6.2. Link Information.......................................12
7. References..................................................12
8. Authors' Addresses..........................................15
Acknowledgment.................................................16
Zhang Expires September 2009 [Page 2]
Internet-Draft OSPF Extensions for WSON March 2009
1. Introduction
Wavelength switched optical networks (WSONs) are based on Wavelength
Division Multiplexing (WDM) in which user traffic is carried by data
channels of different optical wavelengths. In traditional WDM
Networks, each wavelength path is statically configured. With the
deployment of Reconfigurable Optical Add-Drop Multiplexers (ROADMs),
photonic cross-connects (PXCs), and tunable laser, WSONs have become
more dynamic, and operators can flexibly set up wavelength paths to
carry user traffic.
In WSONs where there are no or a limited number of switches capable
of wavelength conversion paths must be set up subject to the
"wavelength continuity" constraint. This leads to a path computation
problem known as routing and wavelength assignment (RWA). In order to
perform such computations, it is necessary to collect information
about the available wavelengths within the network.
[WSON-Frame] provides a framework for applying GMPLS [RFC3945] and
the Path Computation Element (PCE) architecture [RFC4655] to the
control of WSONs to address the RWA problem. [WSON-Info] describes an
information model that specifies the information needed at various
points in a WSON in order to compute paths and establish Label
Switched Paths (LSPs). Based on the information model of [WSON-Info],
[WSON-Encode] provides efficient protocol-independent encodings of
the information needed by the RWA process in a WSON. Such encodings
can be used to extend GMPLS signaling and routing protocols.
Therefore, in order to enable GMPLS to control WSON networks, this
document follows on from [WSON-Info], [WSON-Encode], and [WSON-IGP-
Eval] to define extensions to the OSPF routing protocol to enhance
the Traffic Engineering (TE) properties of GMPLS TE which are defined
in [RFC3630], [RFC4202], and [RFC4203].
No consideration of optical impairment routing related information is
included in this document.
2. Node Information
According to [WSON-Info] and [WSON-Encode], the node information
about WSON nodes includes Node ID, connectivity matrix, wavelength
converter pool information. Except for the Node ID which should
comply with Routing Address described in [RFC3630], the other pieces
of information are defined in this document.
[OSPF-Node] defines a new top TLV named the Node Attribute TLV which
carries attributes related to a router/node. Connectivity matrix,
Zhang Expires September 2009 [Page 3]
Internet-Draft OSPF Extensions for WSON March 2009
wavelength converter pool information are attributes associated with
a WSON node, so this document defines the following sub-TLVs of Node
Attribute TLV:
(1)Connectivity matrix sub-TLV
(2)Wavelength converter pool information sub-TLV
2.1. Connectivity Matrix
Unlike the packet and TDM networks whose switching devices are
symmetric, the switching devices in a WSON are highly asymmetric.
Therefore, it is necessary to identify which ingress ports and
wavelengths can be connected to (the same wavelength on) a specific
egress port. Detailed descriptions of the Connectivity Matrix can be
found in the corresponding sections of [WSON-Info] and [WSON-Encode].
The Connectivity Matrix TLV is a sub-TLV (the type is TBD by IANA) of
the Node Attribute TLV. The format of this sub-TLV is defined as
follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connectivity | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Set A #1 |
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Set B #1 |
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Link set pairs as needed |
: to specify connectivity :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = TBD
Connectivity : 8 bits
The following values are currently defined. All other values are
reserved and SHOULD be transmitted as zero and ignored on receipt.
0x01: Fixed Connectivity Matrix
Zhang Expires September 2009 [Page 4]
Internet-Draft OSPF Extensions for WSON March 2009
Indicates that the switching element is a kind of fixed switching
device, so the connectivity matrix represents the potential
connectivity matrix. This applies to asymmetric fixed devices or to
the fixed part of a "hybrid" device [Switch].
0x02: Switched Connectivity Matrix
Indicates that the switching element is a kind of switched device
(e.g., ROADM or OXC). The connectivity matrix represents the
potential connectivity matrix for an asymmetric switch.
Reserved: 24 bits
This field is reserved. It SHOULD be set to zero on transmission
and MUST be ignored on receipt.
Link Set: At least one Link Set MUST be present. Multiple Link Sets
MAY be present. Each one has variable length. The Link set is defined
in Section 2.2.1..
2.1.1. Link Set
Link Set identifies a link group and is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action |Dir| Format | Num Links | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifier 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifier N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Link Set is not a kind of sub-TLV and it is just a part of the
Connectivity Matrix TLV. (Note that this construct may be reused in
the Wavelength Converter Pool information in Section 2.3 in a future
version of this document.)
Action: 8 bits
The following values are currently defined. All other values are
reserved.
Zhang Expires September 2009 [Page 5]
Internet-Draft OSPF Extensions for WSON March 2009
0x01: Inclusive List
Indicates that one or more link identifiers are included in the
Link Set. Each identifies a separate link that is part of the set.
0x02: Inclusive Range
Indicates that the Link Set defines a range of links. It
contains two link identifiers. The first identifier indicates the
start of the range (inclusive). The second identifier indicates the
end of the range (inclusive). All links with numeric values between
the bounds are considered to be part of the set. A value of zero in
either position indicates that there is no bound on the corresponding
portion of the range. Note that the Action field could be set to
0x02(Inclusive Range) only when unnumbered link identifier is used.
Directionality of the Link Set (Dir): 2 bits
The following values are currently defined. All other values are
reserved.
0x01: Bidirectional
Indicates that the links in the Link Set are bidirectional.
0x02: Incoming
Indicates that the links in the Link Set are from the incoming
direction with respect to the node advertising the information.
0x03: Outgoing
Indicates that the links in the Link Set are to the outgoing
direction with respect to the node advertising the information.
Format: 6 bits
This field identifies the format of the link identifier. The
following values are currently defined. All other values are reserved.
0x01: Link Local Identifier with IPv4 address
Indicates that the links in the Link Set are identified by link
local identifiers which are IPv4 numbered. All link local identifiers
are supplied in the context of the advertising node.
0x02: Link Local Identifier with unnumbered interface
Zhang Expires September 2009 [Page 6]
Internet-Draft OSPF Extensions for WSON March 2009
Indicates that the links in the Link Set are identified by link
local identifiers which are unnumbered interface IDs. All link local
identifiers are supplied in the context of the advertising node.
Num Links: 8 bits
This field indicates the total number of the links in the Link Set.
Reserved: 8 bits
This field is reserved. It MUST be set to zero on transmission
and MUST be ignored on receipt.
Link Identifier: 32 bits for each link
If the Format field is set to 0x01 (Link Local Identifier with
IPv4 address), the link identifier is the interface IP address used
to identify the incoming or outgoing port corresponding to the link.
The format of the Link Identifier should comply with the format of
the Local/Remote Interface IP Address described in [RFC3630].
If the Format field is set to 0x02 (Link Local Identifier with
unnumbered interface), the link identifier is unnumbered.
An example about Connectivity Matrix representation could be referred
to the Section 3.2 of [WSON-Encode].
2.2. Wavelength Converter Pool Information
TBD.
3. Link Information
The most common link sub-TLVs are already defined in [RFC3630],
[RFC4203]. For example, Link ID, Administrative Group, Interface
Switching Capability Descriptor (ISCD), Link Protection Type, Shared
Risk Link Group Information (SRLG), and Traffic Engineering Metric.
For WSONs, per [WSON-Info] and [WSON-Encode], the following
additional link sub-TLVs are defined in this document.
(1) WSON Port Wavelength Restrictions sub-TLV
(2) Wavelength Availability sub-TLV
(3) Shared Backup Wavelengths sub-TLV
Zhang Expires September 2009 [Page 7]
Internet-Draft OSPF Extensions for WSON March 2009
3.1. WSON Port Wavelength Restrictions
In WSONs, there may be wavelength restrictions on a link or port. For
example, a WSON link might only be able to support switching some
specific wavelengths. These restrictions are distributed by OSPF to
be convenient for wavelength path computation.
The WSON Port Wavelength Restrictions TLV is a sub-TLV (the type is
TBD by IANA) of the Link TLV. The format of this sub-TLV is defined
as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RestrictionKind|T| Reserved | MaxNumChannels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength Set |
| (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = TBD
RestrictionKind: 8 bits
The following values are currently defined. All other values are
reserved.
0x01: Simple wavelength selective restriction
In this case, MaxNumChannels indicates the maximum number of
wavelengths permitted on the port, and the accompanying Wavelength
Set indicates the specific permitted wavelengths.
0x02: Waveband device with a tunable center frequency and
passband.
In this case, MaxNumChannels indicates the maximum width of the
waveband in terms of the channels spacing given in the Wavelength Set.
The corresponding wavelength set is used to indicate the overall
tuning range. Specific center frequency tuning information can be
obtained from dynamic channel in use information.
MaxNumChannels indicates the maximum number of channels supported on
the port/waveband dependent on the setting of the RestrictionKind
field.
Zhang Expires September 2009 [Page 8]
Internet-Draft OSPF Extensions for WSON March 2009
Wavelength Set information is carried as defined in Section 3.4 of
[WSON-Encode].
3.2. Wavelength Availability Information
The requirements for a global semantic for wavelength labels and the
corresponding standardized wavelength label can be found in [Lambda-
Labels].
Because the wavelength continuity along the wavelength Label Switched
Path (LSP) should be ensured without wavelength conversion or with
wavelength conversion at some switches along the path, the
information about wavelength availability and wavelength connectivity
is very important when computing a wavelength LSP. For example, if
the wavelength label range [lambda 1, lambda 5] of fiber 1 can be
connected to the same wavelength label range of fiber 2, but only
lambda 3 is available on fiber 2 because other wavelength labels are
occupied, lambda 3 must be selected on fiber 1.
If the wavelength availability information is not known by the node
performing the path computation, then the computation can only be
performed at the level of TE links, and wavelength assignment must be
resolved locally by the switches on a hop-by-hop basis enhanced by
signaling protocol mechanisms used to negotiate label selection.
However, this case may be very inefficient in the signaling protocol,
and can easily lead to blocking problems where a path is selected for
which there is no suitable wavelength availability, unless some or
all of the switches along the path are capable of full wavelength
conversion. In the general case of limited or no wavelength
conversion, information on wavelength availability is essential to
perform efficient and accurate path computation.
It is possible to consider reporting the statuses of each wavelength
on a link using implicit wavelength identification based on the link-
local knowledge of wavelengths supported and a well-known sequence.
However, this information would be of no use in a wider context (i.e.,
away from the link ends). On the other hand, if the standardized
label format described in [Lambda-Labels] is used to identify every
wavelength when its status is reported, the wavelength information
will be a little larger (or the order of one wavelength label per
status advertised). This may have a significant affect on the total
information advertised in a network because a WSON link often
supports many wavelengths (e.g., 80 or 160 wavelength systems).
To minimize the size of information, a bitmap wavelength set is
defined in [WSON-Encode] to indicate the wavelength availability
information for a fiber, i.e., only one bit is used to indicate the
Zhang Expires September 2009 [Page 9]
Internet-Draft OSPF Extensions for WSON March 2009
status of a certain wavelength (the wavelength is either available or
not available).
Note that there are five approaches for Wavelength Set which is used
to represent the wavelength availability information described in
Section 3.4 of [WSON-Encode]. Considering that the continuity of the
available or unavailable wavelength set can be scattered for the
dynamic wavelength availability, so it may burden the routing to
reorganize the wavelength set information when the Inclusive
(/Exclusive) List (/Range) approaches are used to represent
wavelength availability information. Therefore, it is RECOMMENDED
that only the Bitmap Set be used for representation wavelength
availability information as follows.
The Wavelength Availability TLV is a sub-TLV (the type is TBD by
IANA) of the Link TLV. The format of this sub-TLV is defined as
follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num Wavelengths | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Grid | C.S. | Reserved | n for lowest frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bit Map Double-word #1 (Lowest frequency channels) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Bit Map Double-word #N (Highest frequency channels)|Padded bits|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = TBD
The three fields (Grid, C.S. and n) are defined in [Lambda-Label].
Num Wavelengths: 8 bits
Indicates the number of the wavelengths represented by the bit
map.
Each bit in the bit map represents a particular frequency with a
value of 1/0 indicating whether the frequency is available or not.
Bit position zero represents the lowest frequency, while each
succeeding bit position represents the next frequency a channel
spacing (C.S.) above the previous. The values of the bit map are
defined as follows:
Zhang Expires September 2009 [Page 10]
Internet-Draft OSPF Extensions for WSON March 2009
1 = Available
0 = Assigned (in use, or failed, or administratively down, or
under testing)
The valid length of the bit map is clearly Num Wavelengths bits, but
the bit map should be padded to make the whole number of the bits in
bitmap be the time of 32 bits so that the TLV is a multiple of four
bytes. Padded bit SHOULD be set to 0 and MUST be ignored.
Bits that do not represent wavelengths (i.e., those in positions (Num
Wavelengths - 1) and beyond) SHOULD be set to zero and MUST be
ignored.
3.3. Shared Backup Wavelengths
TBD.
4. Procedures for Routing Flooding
The advertisement for the node attributes SHOULD comply with the
procedures described in [OSPF-Node].
In the WSON networks, the node information can be classified as two
kinds: one is static information comparatively such as Node ID,
Connectivity Matrix information; the other is dynamic information
such as Wavelength Converter Pool Status information. For the static
node information, the router announces the static node information in
the node attribute TLV which could be advertised during the node
starts or periodically for some configurable time (e.g., per hour or
several hours). For the dynamic node information, the router
announces this information in the separate node attribute TLV which
SHOULD be advertised during node starts or when the corresponding
node information is changed.
For the WSON link information, the procedures for the routing
flooding SHOULD comply with [RFC3630], [RFC4203] and the other
existing family standards, and there is no extended process for the
link attributes advertisement, except that some link sub-TLVs are
defined in this document.
Note that as with other TE information, an implementation SHOULD take
measures to avoid rapid and frequent updates of routing information
that could cause the routing network to become swamped. A threshold
mechanism MAY be applied such that updates are only flooded when a
Zhang Expires September 2009 [Page 11]
Internet-Draft OSPF Extensions for WSON March 2009
number of changes have been made to the wavelength availability
information within a specific time. Such mechanisms MUST be
configurable if they are implemented.
5. Security Considerations
This document does not introduce any further security issues other
than those discussed in [RFC 3630], [RFC 4203].
6. IANA Considerations
[RFC3630] says that the top level Types in a TE LSA and Types for
sub-TLVs for each top level Types must be assigned by Expert Review,
and must be registered with IANA.
IANA is requested to allocate new Types for the sub-TLVs as defined
in Sections 2.1, 3.1, and 3.2 as follows:
6.1. Node Information
This document introduces the following sub-TLV of Node Attribute TLV
(Value TBD, see [OSPF-Node])
Type sub-TLV
TBD Connectivity matrix
6.2. Link Information
This document introduces the following sub-TLV of TE Link TLV (Value
2)
Type sub-TLV
TBD WSON Port Wavelength Restrictions
TBD Wavelength Availability
7. 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.
Zhang Expires September 2009 [Page 12]
Internet-Draft OSPF Extensions for WSON March 2009
[RFC3630] Katz, D., Kompella, K., and Yeung, D., "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC
3630, September 2003.
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, October 2005.
[RFC3945] E. Mannie, Ed., "OGeneralized Multi-Protocol Label Switching (GMPLS)
Architecture", RFC 3945, October 2004.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture ", RFC 4655,
August 2006.
[OSPF-Node] R. Aggarwal and K. Kompella, "Advertising a Router's
Local Addresses in OSPF TE Extensions", draft-ietf-ospf-
te-node-addr, work in progress.
[Lambda-Labels] T. Otani, H. Guo, K. Miyazaki, D. Caviglia,
"Generalized Labels for G.694 Lambda-Switching
Capable Label Switching Routers", work in progress:
draft-ietf-ccamp-gmpls-g-694-lambda-labels-03.txt,
January 2009.
[WSON-Frame] G. Bernstein, Y. Lee, W. Imajuku, "Framework for GMPLS
and PCE Control of Wavelength Switched Optical
Networks", work in progress: draft-ietf-ccamp-rwa-WSON-
Framework-00.txt, December 2008.
[WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and
Wavelength Assignment Information Model for Wavelength
Switched Optical Networks", work in progress: draft-ietf-
ccamp-rwa-info-01.txt, October 2008.
[WSON-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and
Wavelength Assignment Information Encoding for
Wavelength Switched Optical Networks", work in progress:
draft-ietf-ccamp-rwa-wson-encode-00.txt, December 2008.
Zhang Expires September 2009 [Page 13]
Internet-Draft OSPF Extensions for WSON March 2009
[WSON-IGP-Eval] Dan Li, J. Gao, Y. Lee, "Evaluation of Possible
Interior Gateway Protocol Extensions for Wavelength
Switching Optical Networks", work in progress:
draft-li-ccamp-wson-igp-eval-01.txt, July 2008.
[Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling
WDM Wavelength Switching Systems for use in Automated Path
Computation", http://www.grotto-
networking.com/wson/ModelingWSONswitchesV2a.pdf , June,
2008
Zhang Expires September 2009 [Page 14]
Internet-Draft OSPF Extensions for WSON March 2009
8. Authors' Addresses
Fatai Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972912
Email: zhangfatai@huawei.com
Greg Bernstein
Grotto Networking
Fremont CA, USA
Phone: (510) 573-2237
Email: gregb@grotto-networking.com
Young Lee
Huawei Technologies
1700 Alma Drive, Suite 100
Plano, TX 75075
USA
Phone: (972) 509-5599 (x2240)
Email: ylee@huawei.com
Dan Li
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base,
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28973237
Email: danli@huawei.com
Jianrui Han
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base,
Bantian, Longgang District
Shenzhen 518129 P.R.China
Zhang Expires September 2009 [Page 15]
Internet-Draft OSPF Extensions for WSON March 2009
Phone: +86-755-28972913
Email: hanjianrui@huawei.com
Acknowledgment
TBD.
Intellectual Property
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
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.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
Zhang Expires September 2009 [Page 16]
Internet-Draft OSPF Extensions for WSON March 2009
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
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.
Full Copyright Statement
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Zhang Expires September 2009 [Page 17]