OSPF-TE Protocol Extension for Constraint-aware RSA in Flexi-Grid Networks
draft-zhangj-ccamp-flexi-grid-ospf-te-ext-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Jie Zhang , Ziyan Yu , Yongli Zhao | ||
| Last updated | 2011-10-24 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zhangj-ccamp-flexi-grid-ospf-te-ext-00
Network Working Group J. Zhang
Internet-Draft YL. Zhao
Intended status: Informational ZY. Yu
Expires: April 26, 2012 BUPT
October 24, 2011
OSPF-TE Protocol Extension for Constraint-aware RSA in Flexi-Grid
Networks
draft-zhangj-ccamp-flexi-grid-ospf-te-ext-00
Abstract
ITU-T Study Group 15 has introduced a new flexible grids technology
of DWDM network which is an effective solution to improve the
efficiency of spectrum resource utilization. This memo extends the
OSPF-TE protocol to support constraint-aware routing and spectrum
assignment (RSA) in flexi-grid networks.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 26, 2012.
Copyright Notice
Copyright (c) 2011 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
Zhang, et al. Expires April 26, 2012 [Page 1]
Internet-Draft Routing extension for C-RSA October 2011
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . . 3
3. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Motivation for Routing Protocol Extension . . . . . . . . . . . 4
4.1. Constraints Considerations for RSA in Flexi-Grid
Networks . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Consecutive Spectrum Slots Information . . . . . . . . . . 5
4.3. Variable Guard Band Information . . . . . . . . . . . . . . 5
5. OSPF-TE Protocol Extension . . . . . . . . . . . . . . . . . . 6
5.1. Consecutive Spectrum Slots Weight Sub-TLV . . . . . . . . . 6
5.2. Variable Guard Band Sub-TLV . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Zhang, et al. Expires April 26, 2012 [Page 2]
Internet-Draft Routing extension for C-RSA October 2011
1. Introduction
To enable the dynamic and effective allocation of spectrum resource
based on the demand of the client LSP's requests, the latest revision
of ITU-T Recommendation [G.694.1] has introduced a flexible grid
technique in DWDM optical networks. The flexible grid has a finer
granularity (i.e. according to the definition of flexible grid in
[G.694.1], the data channel can be selected on a channel spacing of
6.25 GHz with a variable slot width measured in units of 12.5 GHz)
for the spectrum slot.
In the dynamic flexi-grid networks, except for selecting an
appropriate route for the client LSP, the appropriate width of
spectrum slot is also needed to choose and assigned to the client
LSP. The spectrum bandwidth assigned to the client LSP is made up of
an appropriate number of consecutive spectrum slots from end-to-end,
which is determined by the used modulation format, according to the
client LSPs data rate requests and physical constraints of the
selected path.
The routing and spectrum assignment (RSA) of flexi-grid networks need
to consider some constraints. In this memo two of those constraints
(other constraints are left for future considered) that are necessary
for RSA are discussed in detail, and then describes the OSPF-TE
protocol extension for these constraints related to RSA in flexi-grid
networks.
2. 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].
3. Terminologies
CSSW: Consecutive spectrum slots weight
GB: Guard band
RSA: Routing and spectrum assignment
WSON: Wavelength switched optical networks
#x27;s SOA.SERIAL, the Update RR is ignored. In the case of a CNAME
Update RR and a non-CNAME Zone RRset or vice versa, ignore the CNAME
Update RR, otherwise replace the CNAME Zone RR with the CNAME Update
RR.
3.4.2.3. For any Update RR whose CLASS is ANY and whose TYPE is ANY,
all Zone RRs with the same NAME are deleted, unless the NAME is the
same as ZNAME in which case only those RRs whose TYPE is other than
SOA or NS are deleted. For any Update RR whose CLASS is ANY and
whose TYPE is not ANY all Zone RRs with the same NAME and TYPE are
deleted, unless the NAME is the same as ZNAME in which case neither
SOA or NS RRs will be deleted.
Vixie, et. al. Standards Track [Page 14]
RFC 2136 DNS Update April 1997
3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose
NAME, TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted,
unless the NAME is the same as ZNAME and either the TYPE is SOA or
the TYPE is NS and the matching Zone RR is the only NS remaining in
the RRset, in which case this Update RR is ignored.
3.4.2.5. Signal NOERROR to the requestor.
3.4.2.6 - Table Of Metavalues Used In Update Section
CLASS TYPE RDATA Meaning
---------------------------------------------------------
ANY ANY empty Delete all RRsets from a name
ANY rrset empty Delete an RRset
NONE rrset rr Delete an RR from an RRset
zone rrset rr Add to an RRset
3.4.2.7 - Pseudocode For Update Section Processing
[rr] for rr in updates
if (rr.class == zclass)
if (rr.type == CNAME)
if (zone_rrset<rr.name, ~CNAME>)
next [rr]
elsif (zone_rrset<rr.name, CNAME>)
next [rr]
if (rr.type == SOA)
if (!zone_rrset<rr.name, SOA> ||
zone_rr<rr.name, SOA>.serial > rr.soa.serial)
next [rr]
for zrr in zone_rrset<rr.name, rr.type>
if (rr.type == CNAME || rr.type == SOA ||
(rr.type == WKS && rr.proto == zrr.proto &&
rr.address == zrr.address) ||
rr.rdata == zrr.rdata)
zrr = rr
next [rr]
zone_rrset<rr.name, rr.type> += rr
elsif (rr.class == ANY)
if (rr.type == ANY)
if (rr.name == zname)
zone_rrset<rr.name, ~(SOA|NS)> = Nil
else
zone_rrset<rr.name, *> = Nil
elsif (rr.name == zname &&
(rr.type == SOA || rr.type == NS))
next [rr]
else
Vixie, et. al. Standards Track [Page 15]
RFC 2136 DNS Update April 1997
zone_rrset<rr.name, rr.type> = Nil
elsif (rr.class == NONE)
if (rr.type == SOA)
next [rr]
if (rr.type == NS && zone_rrset<rr.name, NS> == rr)
next [rr]
zone_rr<rr.name, rr.type, rr.data> = Nil
return (NOERROR)
3.5 - Stability
When a zone is modified by an UPDATE operation, the server must
commit the change to nonvolatile storage before sending a response to
the requestor or answering any queries or transfers for the modified
zone. It is reasonable for a server to store only the update records
as long as a system reboot or power failure will cause these update
records to be incorporated into the zone the next time the server is
started. It is also reasonable for the server to copy the entire
modified zone to nonvolatile storage after each update operation,
though this would have suboptimal performance for large zones.
3.6 - Zone Identity
If the zone's SOA SERIAL is changed by an update operation, that
change must be in a positive direction (using modulo 2**32 arithmetic
as specified by [RFC1982]). Attempts to replace an SOA with one
whose SERIAL is less than the current one will be silently ignored by
the primary master server.
If the zone's SOA's SERIAL is not changed as a result of an update
operation, then the server shall increment it automatically before
the SOA or any changed name or RR or RRset is included in any
response or transfer. The primary master server's implementor might
choose to autoincrement the SOA SERIAL if any of the following events
occurs:
(1) Each update operation.
(2) A name, RR or RRset in the zone has changed and has subsequently
been visible to a DNS client since the unincremented SOA was
visible to a DNS client, and the SOA is about to become visible
to a DNS client.
(3) A configurable period of time has elapsed since the last update
operation. This period shall be less than or equal to one third
of the zone refresh time, and the default shall be the lesser of
that maximum and 300 seconds.
Vixie, et. al. Standards Track [Page 16]
RFC 2136 DNS Update April 1997
(4) A configurable number of updates has been applied since the last
SOA change. The default value for this configuration parameter
shall be one hundred (100).
It is imperative that the zone's contents and the SOA's SERIAL be
tightly synchronized. If the zone appears to change, the SOA must
appear to change as well.
3.7 - Atomicity
During the processing of an UPDATE transaction, the server must
ensure atomicity with respect to other (concurrent) UPDATE or QUERY
transactions. No two transactions can be processed concurrently if
either depends on the final results of the other; in particular, a
QUERY should not be able to retrieve RRsets which have been partially
modified by a concurrent UPDATE, and an UPDATE should not be able to
start from prerequisites that might not still hold at the completion
of some other concurrent UPDATE. Finally, if two UPDATE transactions
would modify the same names, RRs or RRsets, then such UPDATE
transactions must be serialized.
3.8 - Response
At the end of UPDATE processing, a response code will be known. A
response message is generated by copying the ID and Opcode fields
from the request, and either copying the ZOCOUNT, PRCOUNT, UPCOUNT,
and ADCOUNT fields and associated sections, or placing zeros (0) in
the these "count" fields and not including any part of the original
update. The QR bit is set to one (1), and the response is sent back
to the requestor. If the requestor used UDP, then the response will
be sent to the requestor's source UDP port. If the requestor used
TCP, then the response will be sent back on the requestor's open TCP
connection.
4 - Requestor Behaviour
4.1. From a requestor's point of view, any authoritative server for
the zone can appear to be able to process update requests, even
though only the primary master server is actually able to modify the
zone's master file. Requestors are expected to know the name of the
zone they intend to update and to know or be able to determine the
name servers for that zone.
Vixie, et. al. Standards Track [Page 17]
RFC 2136 DNS Update April 1997
4.2. If update ordering is desired, the requestor will need to know
the value of the existing SOA RR. Requestors who update the SOA RR
must update the SOA SERIAL field in a positive direction (as defined
by [RFC1982]) and also preserve the other SOA fields unless the
requestor's explicit intent is to change them. The SOA SERIAL field
must never be set to zero (0).
4.3. If the requestor has reasonable cause to believe that all of a
zone's servers will be equally reachable, then it should arrange to
try the primary master server (as given by the SOA MNAME field if
matched by some NS NSDNAME) first to avoid unnecessary forwarding
inside the slave servers. (Note that the primary master will in some
cases not be reachable by all requestors, due to firewalls or network
partitioning.)
4.4. Once the zone's name servers been found and possibly sorted so
that the ones more likely to be reachable and/or support the UPDATE
opcode are listed first, the requestor composes an UPDATE message of
the following form and sends it to the first name server on its list:
ID: (new)
Opcode: UPDATE
Zone zcount: 1
Zone zname: (zone name)
Zone zclass: (zone class)
Zone ztype: T_SOA
Prerequisite Section: (see previous text)
Update Section: (see previous text)
Additional Data Section: (empty)
4.5. If the requestor receives a response, and the response has an
RCODE other than SERVFAIL or NOTIMP, then the requestor returns an
appropriate response to its caller.
4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP, or
if no response is received within an implementation dependent timeout
period, or if an ICMP error is received indicating that the server's
port is unreachable, then the requestor will delete the unusable
server from its internal name server list and try the next one,
repeating until the name server list is empty. If the requestor runs
out of servers to try, an appropriate error will be returned to the
requestor's caller.
Vixie, et. al. Standards Track [Page 18]
RFC 2136 DNS Update April 1997
5 - Duplicate Detection, Ordering and Mutual Exclusion
5.1. For correct operation, mechanisms may be needed to ensure
idempotence, order UPDATE requests and provide mutual exclusion. An
UPDATE message or response might be delivered zero times, one time,
or multiple times. Datagram duplication is of particular interest
since it covers the case of the so-called "replay attack" where a
correct request is duplicated maliciously by an intruder.
5.2. Multiple UPDATE requests or responses in transit might be
delivered in any order, due to network topology changes or load
balancing, or to multipath forwarding graphs wherein several slave
servers all forward to the primary master. In some cases, it might
be required that the earlier update not be applied after the later
update, where "earlier" and "later" are defined by an external time
base visible to some set of requestors, rather than by the order of
request receipt at the primary master.
5.3. A requestor can ensure transaction idempotence by explicitly
deleting some "marker RR" (rather than deleting the RRset of which it
is a part) and then adding a new "marker RR" with a different RDATA
field. The Prerequisite Section should specify that the original
"marker RR" must be present in order for this UPDATE message to be
accepted by the server.
5.4. If the request is duplicated by a network error, all duplicate
requests will fail since only the first will find the original
"marker RR" present and having its known previous value. The
decisions of whether to use such a "marker RR" and what RR to use are
left up to the application programmer, though one obvious choice is
the zone's SOA RR as described below.
5.5. Requestors can ensure update ordering by externally
synchronizing their use of successive values of the "marker RR."
Mutual exclusion can be addressed as a degenerate case, in that a
single succession of the "marker RR" is all that is needed.
5.6. A special case where update ordering and datagram duplication
intersect is when an RR validly changes to some new value and then
back to its previous value. Without a "marker RR" as described
above, this sequence of updates can leave the zone in an undefined
state if datagrams are duplicated.
5.7. To achieve an atomic multitransaction "read-modify-write" cycle,
a requestor could first retrieve the SOA RR, and build an UPDATE
message one of whose prerequisites was the old SOA RR. It would then
specify updates that would delete this SOA RR and add a new one with
an incremented SOA SERIAL, along with whatever actual prerequisites
Vixie, et. al. Standards Track [Page 19]
RFC 2136 DNS Update April 1997
and updates were the object of the transaction. If the transaction
succeeds, the requestor knows that the RRs being changed were not
otherwise altered by any other requestor.
6 - Forwarding
When a zone slave forwards an UPDATE message upward toward the zone's
primary master server, it must allocate a new ID and prepare to enter
the role of "forwarding server," which is a requestor with respect to
the forward server.
6.1. The set of forward servers will be same as the set of servers
this zone slave would use as the source of AXFR or IXFR data. So,
while the original requestor might have used the zone's NS RRset to
locate its update server, a forwarder always forwards toward its
designated zone master servers.
6.2. If the original requestor used TCP, then the TCP connection from
the requestor is still open and the forwarder must use TCP to forward
the message. If the original requestor used UDP, the forwarder may
use either UDP or TCP to forward the message, at the whim of the
implementor.
6.3. It is reasonable for forward servers to be forwarders
themselves, if the AXFR dependency graph being followed is a deep one
involving firewalls and multiple connectivity realms. In most cases
the AXFR dependency graph will be shallow and the forward server will
be the primary master server.
6.4. The forwarder will not respond to its requestor until it
receives a response from its forward server. UPDATE transactions
involving forwarders are therefore time synchronized with respect to
the original requestor and the primary master server.
6.5. When there are multiple possible sources of AXFR data and
therefore multiple possible forward servers, a forwarder will use the
same fallback strategy with respect to connectivity or timeout errors
that it would use when performing an AXFR. This is implementation
dependent.
6.6. When a forwarder receives a response from a forward server, it
copies this response into a new response message, assigns its
requestor's ID to that message, and sends the response back to the
requestor.
Vixie, et. al. Standards Track [Page 20]
Zhang, et al. Expires April 26, 2012 [Page 3]
Internet-Draft Routing extension for C-RSA October 2011
4. Motivation for Routing Protocol Extension
In this section we introduce the RSA constraints and the motivation
of routing protocol extension for of flexi-grid networks
4.1. Constraints Considerations for RSA in Flexi-Grid Networks
When processing RSA in flexi-grid networks, the constraints
information (such as the information of spectrum bandwidth in a
network link and so on.) are necessary for computing and selecting an
appropriate backup route and a certain number of consecutive spectrum
slots for the client LSPs effectively.
Some of the necessary constraints are listed as follows:
o Spectral consecutiveness constraint
o Variable guard band constraint
o Spectral continuity constraint
o Impairments constraint
o Other constraints
All the constraints can generate important impacts for the
performance of the client LSPs, even for the entire network. The
first two constraints are mainly talked about in this memeo.
Just like the wavelength continuity constraint in WSON, the spectral
continuity constraint means allocation of the same spectrum slots on
each link along a path because not all of the nodes in optical
networks have the ability of wavelength conversion.
The degradation of the optical signals due to impairments that
accumulate along the path (without 3R regeneration), can result in
unacceptable bit error rates or even a complete failure to demodulate
and/or detect the received
signal[draft-ietf-ccamp-wson-impairments-07]. So it is necessary to
consider about the impairments constraint within flexi-grid networks.
The impairments constraint in flexi-grid networks will be studied in
future in this memo.
Also, there may be some other constraints for RSA, other than the
four kinds above, such as the modulation levels constraint, which are
left for future researching.
Zhang, et al. Expires April 26, 2012 [Page 4]
Internet-Draft Routing extension for C-RSA October 2011
4.2. Consecutive Spectrum Slots Information
The spectral consecutiveness constraint is that the allocated
spectrum slots must be chosen from consecutive spectrum slots in the
spectrum space on each link of flexi-grid networks.
Compared with the technology of WSON, the number of spectrum slots in
flexi-grid networks will be much larger than the number of wavelength
in WSON. After a long running time, the situation of available
spectrum slots will be much complex, especially the situation of the
available consecutive spectrum slots.
After selecting a route, the appropriate consecutive spectrum slots
need to be assigned for the client LSP. When we choose one of the
backup routes for the client LSP without considering the situation
about the available consecutive spectrum slots information, the route
may have no enough consecutive spectrum slots which means that the
selected route have no available resource for the LSP's request, and
then the client LSP will be rejected or trigger another path
computation process which will increase the blocking rate of the
network or increase network resources consumed by communication and
computing of new route.
When computing a route with the knowledge of the consecutive spectrum
slots information of the network link (for example, the number of ten
available consecutive spectrum slots in a network link, or the number
of twenty available consecutive spectrum slots in a network link.),
it will be very useful to select a better route which has higher
probability of enough available consecutive spectrum slots for the
client LSP. And this will improve the success rate of setting up new
client LSPs.
4.3. Variable Guard Band Information
Some spectrum slots need to be reserved as Guard Band(GB) between two
adjacent client LSPs to avoid bad impact of non-linear impairments
and other network elements. Since the granularity of the flexi-grid
networks will be very small, the spectrum interval, i.e., GB need to
be considered more carefully to avoid poor quality impact of the
adjacent client LSPs. Which means with the changing of network
environment and the operating of the network, the bandwidth of the GB
also need to change.
In flexi-grid networks, with the increasing of the total
transportation power and the smaller of the channel space, the
channel crosstalk that results from non-linear effects will become
the important factor that affects the performance of the network.
The impact between two adjacency client LSPs may be changing based on
Zhang, et al. Expires April 26, 2012 [Page 5]
Internet-Draft Routing extension for C-RSA October 2011
the change of crosstalk and other changes of network. With the
changing of those parameters, the interferences between two adjacency
client LSPs may be increasing, if the Guard Band is fixed, the
quality of the adjacent client LSPs and also the network's will be
decreased. If the GB can be varied based on the network environment
changing, then the bad impact can be avoided.
5. OSPF-TE Protocol Extension
In this section, we define the enhancements to the Traffic
Engineering (TE) properties of flexi-grid networks' TE links that can
be announced in OSPF-TE LSAs.
The TE LSA, which is an opaque 10 LSA with area flooding scope
[RFC3630], has only one top-level and has one or more nested sub-TLVs
for extensibility. [RFC3630] also defines two top Type/Length/Value
(TLV) triplet to support traffic engineering of OSPF, i.e. (1) Router
Address TLV and (2) Link TLV. In this memo, we enhance the sub-TLVs
for the Link TLV in support of flexi-grid networks. Specifically, we
add the following sub-TLVs to the Link TLV:
o Consecutive spectrum slots weight sub-TLV
o Variable Guard Band sub-TLV
5.1. Consecutive Spectrum Slots Weight Sub-TLV
In distribution networks, we propose the CSSW as a sub-TLV of OSPF-TE
Link TLV which represents the situation of the available consecutive
spectrum slots in a link of the flexi-grid networks for example the
percentage of the total bandwidth of the number of five consecutive
spectrum slots, the percentage of the total bandwidth of the number
of ten consecutive spectrum slots ... ). With knowing the weight of
available consecutive spectrum slots in a link, the spectrum resource
assignment in the flexi-grid networks can be working more
efficiently.
The format of the CSSW sub-TLV is as follows:
Zhang, et al. Expires April 26, 2012 [Page 6]
Internet-Draft Routing extension for C-RSA October 2011
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 = TBD | Length = variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value = Consecutive Spectrum Slots Weight |
// //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD.
The Type of CSSW sub-TLV is left for future to define.
Length: Variable.
The length of CSSW sub-TLV is based on its define of the value which
is variable based on different implementation ways.
Value: TBD
The content of the CSSW sub-TLV is left for future researching.
5.2. Variable Guard Band Sub-TLV
The Guard Band sub-TLV (which is also short for GB sub-TLV) describes
the spectrum interval between two client LSPs to avoid crosstalk and
other network elements(such as impairment elements) that can affect
the transmission performance of each client LSP.
The format of the GB sub-TLV is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length = TBD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value = Variable Guard Band |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD.
The Type of GB sub-TLV is left for future to define.
Zhang, et al. Expires April 26, 2012 [Page 7]
Internet-Draft Routing extension for C-RSA October 2011
Length: TBD.
The length of CSSW sub-TLV is based on the define of the value of it.
Value: TBD.
The content of the CSSW sub-TLV and it is left for future
researching.
6. Security Considerations
TBD.
7. Acknowledgments
TBD.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFC's to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
8.2. Informative References
[draft-ietf-ccamp-wson-impairments-07]
Lee, Y., Bernstein, G., Li, D., and G. Martinelli, "A
Framework for the Control of Wavelength Switched Optical
Networks (WSON) with Impairments", July 2011.
Zhang, et al. Expires April 26, 2012 [Page 8]
Internet-Draft Routing extension for C-RSA October 2011
Authors' Addresses
Jie Zhang
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8613911060930
Email: lgr24@bupt.edu.cn
URI: http://www.bupt.edu.cn/
Yongli Zhao
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8613811761857
Email: yonglizhao@bupt.edu.cn
URI: http://www.bupt.edu.cn/
Ziyan Yu
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8615116984347
Email: yzhziyan@gmail.com
URI: http://www.bupt.edu.cn/
Zhang, et al. Expires April 26, 2012 [Page 9]