draft-ietf-ccamp-rwa-info-05.txt | draft-ietf-ccamp-rwa-info-06.txt | |||
---|---|---|---|---|
Network Working Group Y. Lee | Network Working Group Y. Lee | |||
Internet Draft Huawei | Internet Draft Huawei | |||
Intended status: Informational G. Bernstein | Intended status: Informational G. Bernstein | |||
Expires: April 2010 Grotto Networking | Expires: August 2010 Grotto Networking | |||
D. Li | D. Li | |||
Huawei | Huawei | |||
W. Imajuku | W. Imajuku | |||
NTT | NTT | |||
October 9, 2009 | February 8, 2010 | |||
Routing and Wavelength Assignment Information Model for Wavelength | Routing and Wavelength Assignment Information Model for Wavelength | |||
Switched Optical Networks | Switched Optical Networks | |||
draft-ietf-ccamp-rwa-info-05.txt | draft-ietf-ccamp-rwa-info-06.txt | |||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
skipping to change at page 1, line 39 | skipping to change at page 1, line 39 | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html | http://www.ietf.org/shadow.html | |||
This Internet-Draft will expire on April 9, 2009. | This Internet-Draft will expire on August 8, 2010. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2009 IETF Trust and the persons identified as the | Copyright (c) 2010 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents in effect on the date of | Provisions Relating to IETF Documents | |||
publication of this document (http://trustee.ietf.org/license-info). | (http://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | ||||
include Simplified BSD License text as described in Section 4.e of | ||||
the Trust Legal Provisions and are provided without warranty as | ||||
described in the Simplified BSD License. | ||||
Abstract | Abstract | |||
This document provides a model of information needed by the routing | This document provides a model of information needed by the routing | |||
and wavelength assignment (RWA) process in wavelength switched | and wavelength assignment (RWA) process in wavelength switched | |||
optical networks (WSONs). The purpose of the information described | optical networks (WSONs). The purpose of the information described | |||
in this model is to facilitate constrained lightpath computation in | in this model is to facilitate constrained lightpath computation in | |||
WSONs, particularly in cases where there are no or a limited number | WSONs. This model takes into account compatibility constraints | |||
of wavelength converters available. This model does not include | between WSON signal attributes and network elements but does not | |||
optical impairments. | include constraints due to optical impairments. Aspects of this | |||
information that may be of use to other technologies utilizing a | ||||
GMPLS control plane are discussed. | ||||
Table of Contents | Table of Contents | |||
1. Introduction...................................................3 | 1. Introduction...................................................3 | |||
1.1. Revision History..........................................3 | 1.1. Revision History..........................................4 | |||
1.1.1. Changes from 01......................................3 | 1.1.1. Changes from 01......................................4 | |||
1.1.2. Changes from 02......................................3 | 1.1.2. Changes from 02......................................4 | |||
1.1.3. Changes from 03......................................4 | 1.1.3. Changes from 03......................................4 | |||
1.1.4. Changes from 04......................................4 | 1.1.4. Changes from 04......................................4 | |||
2. Terminology....................................................4 | 1.1.5. Changes from 05......................................5 | |||
2. Terminology....................................................5 | ||||
3. Routing and Wavelength Assignment Information Model............5 | 3. Routing and Wavelength Assignment Information Model............5 | |||
3.1. Dynamic and Relatively Static Information.................5 | 3.1. Dynamic and Relatively Static Information.................6 | |||
3.2. Node Information..........................................6 | 4. Node Information (General).....................................6 | |||
3.2.1. Connectivity Matrix..................................6 | 4.1. Connectivity Matrix.......................................7 | |||
3.2.2. Shared Risk Node Group...............................7 | 4.2. Shared Risk Node Group....................................8 | |||
3.2.3. Wavelength Converter Pool............................7 | 5. Node Information (WSON specific)...............................8 | |||
3.2.4. OEO Wavelength Converter Info.......................10 | 5.1. Resource Accessibility/Availability.......................9 | |||
3.3. Link Information.........................................10 | 5.2. Resource Signal Constraints and Processing Capabilities..11 | |||
3.3.1. Administrative Group................................10 | 5.3. Compatibility and Capability Details.....................11 | |||
3.3.2. Interface Switching Capability Descriptor...........11 | 5.3.1. Modulation Type List................................11 | |||
3.3.3. Link Protection Type (for this link)................11 | 5.3.2. FEC Type List.......................................12 | |||
3.3.4. Shared Risk Link Group Information..................11 | 5.3.3. Bit Rate Range List.................................12 | |||
3.3.5. Traffic Engineering Metric..........................11 | 5.3.4. Acceptable Client Signal List.......................12 | |||
3.3.6. Port Wavelength (label) Restrictions................11 | 5.3.5. Processing Capability List..........................12 | |||
3.4. Dynamic Link Information.................................13 | 6. Link Information (General)....................................13 | |||
3.5. Dynamic Node Information.................................13 | 6.1. Administrative Group.....................................13 | |||
4. Security Considerations.......................................14 | 6.2. Interface Switching Capability Descriptor................13 | |||
5. IANA Considerations...........................................14 | 6.3. Link Protection Type (for this link).....................14 | |||
6. Acknowledgments...............................................14 | 6.4. Shared Risk Link Group Information.......................14 | |||
7. References....................................................15 | 6.5. Traffic Engineering Metric...............................14 | |||
7.1. Normative References.....................................15 | 6.6. Port Label (Wavelength) Restrictions.....................14 | |||
7.2. Informative References...................................15 | 7. Dynamic Components of the Information Model...................16 | |||
8. Contributors..................................................16 | 7.1. Dynamic Link Information (General).......................16 | |||
Author's Addresses...............................................17 | 7.2. Dynamic Node Information (WSON Specific).................16 | |||
Intellectual Property Statement..................................17 | 8. Security Considerations.......................................17 | |||
Disclaimer of Validity...........................................18 | 9. IANA Considerations...........................................17 | |||
10. Acknowledgments..............................................17 | ||||
11. References...................................................18 | ||||
11.1. Normative References....................................18 | ||||
11.2. Informative References..................................19 | ||||
12. Contributors.................................................20 | ||||
Author's Addresses...............................................20 | ||||
Intellectual Property Statement..................................21 | ||||
Disclaimer of Validity...........................................22 | ||||
1. Introduction | 1. Introduction | |||
The purpose of the following information model for WSONs is to | The purpose of the following information model for WSONs is to | |||
facilitate constrained lightpath computation and as such is not a | facilitate constrained lightpath computation and as such is not a | |||
general purpose network management information model. In particular | general purpose network management information model. This constraint | |||
this model has particular value in the cases where there are no or a | is frequently referred to as the "wavelength continuity" constraint, | |||
limited number of wavelength converters available in the WSON. This | and the corresponding constrained lightpath computation is known as | |||
constraint is frequently referred to as the "wavelength continuity" | the routing and wavelength assignment (RWA) problem. Hence the | |||
constraint, and the corresponding constrained lightpath computation | information model must provide sufficient topology and wavelength | |||
is known as the routing and wavelength assignment (RWA) problem. | restriction and availability information to support this computation. | |||
Hence the information model must provide sufficient topology and | More details on the RWA process and WSON subsystems and their | |||
wavelength restriction and availability information to support this | properties can be found in [WSON-Frame]. The model defined here | |||
computation. More details on the RWA process and WSON subsystems and | includes constraints between WSON signal attributes and network | |||
their properties can be found in [WSON-Frame]. The model defined here | elements, but does not include optical impairments. | |||
does not currently include impairments however optical impairments | ||||
can be accommodated by the general framework presented here. | ||||
1.1. Revision History | In addition to presenting an information model suitable for path | |||
computation in WSON, this document also highlights model aspects that | ||||
may have general applicability to other technologies utilizing a | ||||
GMPLS control plane. We refer to the information model applicable to | ||||
other technologies beyond WSON as "general" to distinguish from the | ||||
"WSON-specific" model that is applicable only to WSON technology. | ||||
1.1. Revision History | ||||
1.1.1. Changes from 01 | 1.1.1. Changes from 01 | |||
Added text on multiple fixed and switched connectivity matrices. | Added text on multiple fixed and switched connectivity matrices. | |||
Added text on the relationship between SRNG and SRLG and encoding | Added text on the relationship between SRNG and SRLG and encoding | |||
considerations. | considerations. | |||
Added clarifying text on the meaning and use of port/wavelength | Added clarifying text on the meaning and use of port/wavelength | |||
restrictions. | restrictions. | |||
skipping to change at page 4, line 24 | skipping to change at page 4, line 51 | |||
1.1.3. Changes from 03 | 1.1.3. Changes from 03 | |||
Removed signal related text from section 3.2.4 as signal related | Removed signal related text from section 3.2.4 as signal related | |||
information is deferred to a new signal compatibility draft. | information is deferred to a new signal compatibility draft. | |||
Removed encoding specific text from Section 3.3.1 of version 03. | Removed encoding specific text from Section 3.3.1 of version 03. | |||
1.1.4. Changes from 04 | 1.1.4. Changes from 04 | |||
Removed encoding specific text from Section 3.2.1. | Removed encoding specific text from Section 4.1. | |||
Removed encoding specific text from Section 3.4. | Removed encoding specific text from Section 3.4. | |||
1.1.5. Changes from 05 | ||||
Renumbered sections for clarity. | ||||
Updated abstract and introduction to encompass signal | ||||
compatibility/generalization. | ||||
Generalized Section on wavelength converter pools to include electro | ||||
optical subsystems in general. This is where we added signal | ||||
compatibility modeling. | ||||
2. Terminology | 2. Terminology | |||
CWDM: Coarse Wavelength Division Multiplexing. | CWDM: Coarse Wavelength Division Multiplexing. | |||
DWDM: Dense Wavelength Division Multiplexing. | DWDM: Dense Wavelength Division Multiplexing. | |||
FOADM: Fixed Optical Add/Drop Multiplexer. | FOADM: Fixed Optical Add/Drop Multiplexer. | |||
ROADM: Reconfigurable Optical Add/Drop Multiplexer. A reduced port | ROADM: Reconfigurable Optical Add/Drop Multiplexer. A reduced port | |||
count wavelength selective switching element featuring ingress and | count wavelength selective switching element featuring ingress and | |||
skipping to change at page 5, line 26 | skipping to change at page 6, line 16 | |||
o Link Information | o Link Information | |||
o Dynamic Node Information | o Dynamic Node Information | |||
o Dynamic Link Information | o Dynamic Link Information | |||
Note that this is roughly the categorization used in [G.7715] section | Note that this is roughly the categorization used in [G.7715] section | |||
7. | 7. | |||
In the following we use where applicable the reduced Backus-Naur form | In the following we use, where applicable, the reduced Backus-Naur | |||
(RBNF) syntax of [RBNF] to aid in defining the RWA information model. | form (RBNF) syntax of [RBNF] to aid in defining the RWA information | |||
model. | ||||
3.1. Dynamic and Relatively Static Information | 3.1. Dynamic and Relatively Static Information | |||
All the RWA information of concern in a WSON network is subject to | All the RWA information of concern in a WSON network is subject to | |||
change over time. Equipment can be upgraded; links may be placed in | change over time. Equipment can be upgraded; links may be placed in | |||
or out of service and the like. However, from the point of view of | or out of service and the like. However, from the point of view of | |||
RWA computations there is a difference between information that can | RWA computations there is a difference between information that can | |||
change with each successive connection establishment in the network | change with each successive connection establishment in the network | |||
and that information that is relatively static on the time scales of | and that information that is relatively static on the time scales of | |||
connection establishment. A key example of the former is link | connection establishment. A key example of the former is link | |||
wavelength usage since this can change with connection setup/teardown | wavelength usage since this can change with connection setup/teardown | |||
and this information is a key input to the RWA process. Examples of | and this information is a key input to the RWA process. Examples of | |||
relatively static information are the potential port connectivity of | relatively static information are the potential port connectivity of | |||
a WDM ROADM, and the channel spacing on a WDM link. | a WDM ROADM, and the channel spacing on a WDM link. | |||
In this document we will separate, where possible, dynamic and static | In this document we will separate, where possible, dynamic and static | |||
information so that these can be kept separate in possible encodings | information so that these can be kept separate in possible encodings | |||
and hence allowing for separate updates of these two types of | and hence allowing for separate updates of these two types of | |||
information thereby reducing processing and traffic load caused by | information thereby reducing processing and traffic load caused by | |||
the timely distribution of the more dynamic RWA WSON information. | the timely distribution of the more dynamic RWA WSON information. | |||
3.2. Node Information | 4. Node Information (General) | |||
The node information described here contains the relatively static | The node information described here contains the relatively static | |||
information related to a WSON node. This includes connectivity | information related to a WSON node. This includes connectivity | |||
constraints amongst ports and wavelengths since WSON switches can | constraints amongst ports and wavelengths since WSON switches can | |||
exhibit asymmetric switching properties. Additional information could | exhibit asymmetric switching properties. Additional information could | |||
include properties of wavelength converters in the node if any are | include properties of wavelength converters in the node if any are | |||
present. In [Switch] it was shown that the wavelength connectivity | present. In [Switch] it was shown that the wavelength connectivity | |||
constraints for a large class of practical WSON devices can be | constraints for a large class of practical WSON devices can be | |||
modeled via switched and fixed connectivity matrices along with | modeled via switched and fixed connectivity matrices along with | |||
corresponding switched and fixed port constraints. We include these | corresponding switched and fixed port constraints. We include these | |||
connectivity matrices with our node information the switched and | connectivity matrices with our node information the switched and | |||
fixed port wavelength constraints with the link information. | fixed port wavelength constraints with the link information. | |||
Formally, | Formally, | |||
<Node_Information> ::= <Node_ID> [<ConnectivityMatrix>...] | <Node_Information> ::= <Node_ID> [<ConnectivityMatrix>...] | |||
[<WavelengthConverterPool>] | ||||
Where the Node_ID would be an appropriate identifier for the node | Where the Node_ID would be an appropriate identifier for the node | |||
within the WSON RWA context. | within the WSON RWA context. | |||
Note that multiple connectivity matrices are allowed and hence can | Note that multiple connectivity matrices are allowed and hence can | |||
fully support the most general cases enumerated in [Switch]. | fully support the most general cases enumerated in [Switch]. | |||
3.2.1. Connectivity Matrix | 4.1. Connectivity Matrix | |||
The connectivity matrix (ConnectivityMatrix) represents either the | The connectivity matrix (ConnectivityMatrix) represents either the | |||
potential connectivity matrix for asymmetric switches (e.g. ROADMs | potential connectivity matrix for asymmetric switches (e.g. ROADMs | |||
and such) or fixed connectivity for an asymmetric device such as a | and such) or fixed connectivity for an asymmetric device such as a | |||
multiplexer. Note that this matrix does not represent any particular | multiplexer. Note that this matrix does not represent any particular | |||
internal blocking behavior but indicates which ingress ports and | internal blocking behavior but indicates which ingress ports and | |||
wavelengths could possibly be connected to a particular output port. | wavelengths could possibly be connected to a particular output port. | |||
Representing internal state dependent blocking for a switch or ROADM | Representing internal state dependent blocking for a switch or ROADM | |||
is beyond the scope of this document and due to it's highly | is beyond the scope of this document and due to it's highly | |||
implementation dependent nature would not be subject to | implementation dependent nature would most likely not be subject to | |||
standardization. This is a conceptual M by N matrix representing the | standardization in the future. The connectivity matrix is a | |||
potential switched or fixed connectivity, where M represents the | conceptual M by N matrix representing the potential switched or fixed | |||
number of ingress ports and N the number of egress ports. We say this | connectivity, where M represents the number of ingress ports and N | |||
is a "conceptual" since this matrix tends to exhibit structure that | the number of egress ports. We say this is a "conceptual" matrix | |||
allows for very compact representations that are useful for both | since this matrix tends to exhibit structure that allows for very | |||
transmission and path computation [Encode]. | compact representations that are useful for both transmission and | |||
path computation [Encode]. | ||||
Note that the connectivity matrix concept can be useful in any | Note that the connectivity matrix information element can be useful | |||
context where asymmetric switches are utilized. | in any technology context where asymmetric switches are utilized. | |||
ConnectivityMatrix(i, j) ::= <MatrixID> <ConnType> <Matrix> | ConnectivityMatrix(i, j) ::= <MatrixID> <ConnType> <Matrix> | |||
Where | Where | |||
<MatrixID> is a unique identifier for the matrix. | <MatrixID> is a unique identifier for the matrix. | |||
<ConnType> can be either 0 or 1 depending upon whether the | <ConnType> can be either 0 or 1 depending upon whether the | |||
connectivity is either fixed or potentially switched. | connectivity is either fixed or potentially switched. | |||
<Matrix> represents the fixed or switched connectivity in that | <Matrix> represents the fixed or switched connectivity in that | |||
Matrix(i, j) = 0 or 1 depending on whether ingress port i can connect | Matrix(i, j) = 0 or 1 depending on whether ingress port i can connect | |||
to egress port j for one or more wavelengths. | to egress port j for one or more wavelengths. | |||
skipping to change at page 7, line 15 | skipping to change at page 8, line 5 | |||
<MatrixID> is a unique identifier for the matrix. | <MatrixID> is a unique identifier for the matrix. | |||
<ConnType> can be either 0 or 1 depending upon whether the | <ConnType> can be either 0 or 1 depending upon whether the | |||
connectivity is either fixed or potentially switched. | connectivity is either fixed or potentially switched. | |||
<Matrix> represents the fixed or switched connectivity in that | <Matrix> represents the fixed or switched connectivity in that | |||
Matrix(i, j) = 0 or 1 depending on whether ingress port i can connect | Matrix(i, j) = 0 or 1 depending on whether ingress port i can connect | |||
to egress port j for one or more wavelengths. | to egress port j for one or more wavelengths. | |||
3.2.2. Shared Risk Node Group | 4.2. Shared Risk Node Group | |||
SRNG: Shared risk group for nodes. The concept of a shared risk link | SRNG: Shared risk group for nodes. The concept of a shared risk link | |||
group was defined in [RFC4202]. This can be used to achieve a desired | group was defined in [RFC4202]. This can be used to achieve a desired | |||
"amount" of link diversity. It is also desirable to have a similar | "amount" of link diversity. It is also desirable to have a similar | |||
capability to achieve various degrees of node diversity. This is | capability to achieve various degrees of node diversity. This is | |||
explained in [G.7715]. Typical risk groupings for nodes can include | explained in [G.7715]. Typical risk groupings for nodes can include | |||
those nodes in the same building, within the same city, or geographic | those nodes in the same building, within the same city, or geographic | |||
region. | region. | |||
Since the failure of a node implies the failure of all links | Since the failure of a node implies the failure of all links | |||
associated with that node a sufficiently general shared risk link | associated with that node a sufficiently general shared risk link | |||
group (SRLG) encoding, such as that used in GMPLS routing extensions | group (SRLG) encoding, such as that used in GMPLS routing extensions | |||
can explicitly incorporate SRNG information. | can explicitly incorporate SRNG information. | |||
3.2.3. Wavelength Converter Pool | 5. Node Information (WSON specific) | |||
A WSON node may include wavelength converters. These are usually | As discussed in [WSON-Frame] a WSON node may contain electro-optical | |||
arranged into some type of pool to promote resource sharing. There | subsystems such as regenerators, wavelength converters or entire | |||
are a number of different approaches used in the design of switches | switching subsystems. The model present here can be used in | |||
with converter pools. However, from the point of view of path | characterizing the accessibility and availability of limited | |||
computation we need to know the following: | resources such as regenerators or wavelength converters as well as | |||
WSON signal attribute constraints of electro-optical subsystems. As | ||||
such this information element is fairly specific to WSON | ||||
technologies. We refer to regenerator block or wavelength converter | ||||
block as resource block. | ||||
1. The nodes that support wavelength conversion. | A WSON node may include regenerators or wavelength converters | |||
arranged in a shared pool. As discussed in [WSON-Frame] this can | ||||
include OEO based WDM switches as well. There are a number of | ||||
different approaches used in the design of WDM switches containing | ||||
regenerator or converter pools. However, from the point of view of | ||||
path computation we need to know the following: | ||||
1. The nodes that support regeneration or wavelength conversion. | ||||
2. The accessibility and availability of a wavelength converter to | 2. The accessibility and availability of a wavelength converter to | |||
convert from a given ingress wavelength on a particular ingress | convert from a given ingress wavelength on a particular ingress | |||
port to a desired egress wavelength on a particular egress port. | port to a desired egress wavelength on a particular egress port. | |||
3. Limitations on the types of signals that can be converted and the | 3. Limitations on the types of signals that can be converted and the | |||
conversions that can be performed. | conversions that can be performed. | |||
To model point 2 above we can use a similar technique as used to | <Node_Information> ::= <Node_ID> [<ConnectivityMatrix>...] | |||
model ROADMs and optical switches this technique was generally | [<ResourcePool>] [<ResourceProperties>] | |||
discussed in [WSON-Frame] and consisted of a matrix to indicate | 5.1. Resource Accessibility/Availability | |||
possible connectivity along with wavelength constraints for | ||||
links/ports. Since wavelength converters are considered a scarce | ||||
resource we will also want to our model to include as a minimum the | ||||
usage state of individual wavelength converters in the pool. Models | ||||
that incorporate more state to further reveal blocking conditions on | ||||
ingress or egress to particular converters are for further study. | ||||
We utilize a three stage model as shown schematically in Figure 1. In | A similar technique as used to model ROADMs and optical switches can | |||
this model we assume N ingress ports (fibers), P wavelength | be used to model regenerator/converter accessibility. This technique | |||
converters, and M egress ports (fibers). Since not all ingress ports | was generally discussed in [WSON-Frame] and consisted of a matrix to | |||
can necessarily reach the converter pool, the model starts with a | indicate possible connectivity along with wavelength constraints for | |||
wavelength pool ingress matrix WI(i,p) = {0,1} whether ingress port i | links/ports. Since regenerators or wavelength converters may be | |||
can reach potentially reach wavelength converter p. | considered a scarce resource we will also want to our model to | |||
include as a minimum the usage state (availability) of individual | ||||
regenerators or converters in the pool. Models that incorporate more | ||||
state to further reveal blocking conditions on ingress or egress to | ||||
particular converters are for further study and not included here. | ||||
Since not all wavelengths can necessarily reach all the converters or | The three stage model as shown schematically in Figure 1. In this | |||
the converters may have limited input wavelength range we have a set | model we assume N ingress ports (fibers), P resource blocks | |||
of ingress port constraints for each wavelength converter. Currently | containing one or more identical resources (e.g. wavelength | |||
we assume that a wavelength converter can only take a single | converters), and M egress ports (fibers). Since not all ingress ports | |||
wavelength on input. We can model each wavelength converter ingress | can necessarily reach each resource block, the model starts with a | |||
port constraint via a wavelength set mechanism. | resource pool ingress matrix RI(i,p) = {0,1} whether ingress port i | |||
can reach potentially reach resource block p. | ||||
Next we have a state vector WC(j) = {0,1} dependent upon whether | Since not all wavelengths can necessarily reach all the resources or | |||
wavelength converter j in the pool is in use. This is the only state | the resources may have limited input wavelength range we have a set | |||
kept in the converter pool model. This state is not necessary for | of ingress port constraints for each resource. Currently we assume | |||
modeling "fixed" transponder system, i.e., systems where there is no | that a resource with a resource block can only take a single | |||
sharing. In addition, this state information may be encoded in a | wavelength on input. We can model each resource block ingress port | |||
much more compact form depending on the overall connectivity | constraint via a wavelength set mechanism. | |||
structure [WC-Pool]. | ||||
After that, we have a set of wavelength converter egress wavelength | Next we have a state vector RA(j) = {0,...,k} which tells us the | |||
constraints. These constraints indicate what wavelengths a particular | number of resources in resource block j in use. This is the only | |||
wavelength converter can generate or are restricted to generating due | state kept in the resource pool model. This state is not necessary | |||
to internal switch structure. | for modeling "fixed" transponder system or full OEO switches with WDM | |||
interfaces, i.e., systems where there is no sharing. | ||||
Finally, we have a wavelength pool egress matrix WE(p,k) = {0,1} | After that, we have a set of resource egress wavelength constraints. | |||
depending on whether the output from wavelength converter p can reach | These constraints indicate what wavelengths a particular resource | |||
block can generate or are restricted to generating e.g., a fixed | ||||
regenerator would be limited to a single lambda. | ||||
Finally, we have a resource pool egress matrix RE(p,k) = {0,1} | ||||
depending on whether the output from resource block p can reach | ||||
egress port k. Examples of this method being used to model wavelength | egress port k. Examples of this method being used to model wavelength | |||
converter pools for several switch architectures from the literature | converter pools for several switch architectures from the literature | |||
are given in reference [WC-Pool]. | are given in reference [WC-Pool]. | |||
I1 +-------------+ +-------------+ E1 | I1 +-------------+ +-------------+ E1 | |||
----->| | +--------+ | |-----> | ----->| | +--------+ | |-----> | |||
I2 | +------+ WC #1 +-------+ | E2 | I2 | +------+ Rb #1 +-------+ | E2 | |||
----->| | +--------+ | |-----> | ----->| | +--------+ | |-----> | |||
| Wavelength | | Wavelength | | | | | | | |||
| Converter | +--------+ | Converter | | | Resource | +--------+ | Resource | | |||
| Pool +------+ WC #2 +-------+ Pool | | | Pool +------+ +-------+ Pool | | |||
| | +--------+ | | | | | + Rb #2 + | | | |||
| Ingress | | Egress | | | Ingress +------+ +-------| Egress | | |||
| Connection | . | Connection | | | Connection | +--------+ | Connection | | |||
| Matrix | . | Matrix | | | Matrix | . | Matrix | | |||
| | . | | | | | . | | | |||
| | | | | | | . | | | |||
IN | | +--------+ | | EM | IN | | +--------+ | | EM | |||
----->| +------+ WC #P +-------+ |-----> | ----->| +------+ Rb #P +-------+ |-----> | |||
| | +--------+ | | | | | +--------+ | | | |||
+-------------+ ^ ^ +-------------+ | +-------------+ ^ ^ +-------------+ | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
Ingress wavelength Egress wavelength | Ingress wavelength Egress wavelength | |||
constraints for constraints for | constraints for constraints for | |||
each converter each converter | each resource each resource | |||
Figure 1 Schematic diagram of wavelength converter pool model. | Figure 1 Schematic diagram of resource pool model. | |||
Formally we can specify the model as: | Formally we can specify the model as: | |||
<WavelengthConverterPool> ::= <PoolIngressMatrix> | <ResourcePool> ::= <ResourceBlockInfo><PoolIngressMatrix> | |||
<IngressPoolConstraints> [<WCPoolState>] <EgressPoolConstraints> | <IngressWaveConstraints> [<ResourcePoolState>] | |||
<PoolEgressMatrix> | <EgressWaveConstraints> <PoolEgressMatrix> | |||
Note that except for <WCPoolState> all the other components of | ||||
<WavelengthConverterPool> are relatively static. In addition | ||||
<WCPoolState> is a relatively small structure compared potentially to | ||||
the others and hence in a future revision of this document maybe | ||||
moved to a new section on dynamic node information. | ||||
3.2.4. OEO Wavelength Converter Info | Where | |||
An OEO based wavelength converter can be characterized by an input | <ResourceBlockInfo>:=(<ResourceBlockID><ResourceBlockSize>)... | |||
wavelength set and an output wavelength set. Such a wavelength | ||||
converter can be modeled by: | ||||
<OEOWavelengthConverterInfo> ::= [<InputWavelengthSet>] | <ResourcePoolState>:=(<ResourceBlockID><NumResourcesInUse>)... | |||
[<OutputWavelengthSet>] | ||||
3.3. Link Information | Note that except for <ResourcePoolState> all the other components of | |||
<ResourcePool> are relatively static. | ||||
5.2. Resource Signal Constraints and Processing Capabilities | ||||
The wavelength conversion abilities of a resource (e.g. regenerator, | ||||
wavelength converter) were modeled in the <EgressWaveConstraints> | ||||
previously discussed. As discussed in [WSON-Frame] we can model the | ||||
constraints on an electro-optical resource in terms of input | ||||
constraints, processing capabilities, and output constraints: | ||||
<ResourceProperties> ::= | ||||
([<ResourceSet>]<InputConstraints><ProcessingCapabilities><OutputCons | ||||
traints>)* | ||||
Where <ResourceSet> is a list of resource block identifiers with the | ||||
same characteristics. If this set is missing the constraints are | ||||
applied to the entire network element. | ||||
The <InputConstraints> are signal compatibility based constraints. | ||||
The details of these constraints are defined in section 5.3. | ||||
<InputConstraints> ::= | ||||
<ModulationTypeList><FECTypeList><BitRateRange><ClientSignalList> | ||||
The <ProcessingCapabilities> are important operations that the | ||||
resource (or network element) can perform on the signal. The details | ||||
of these capabilities are defined in section 5.3. | ||||
<ProcessingCapabilities> ::= | ||||
<RegenerationCapabilities><FaultPerfMon><VendorSpecific> | ||||
The <OutputConstraints> are either restrictions on the properties of | ||||
the signal leaving the resource or network element or options | ||||
concerning the signal properties when leaving the resource or network | ||||
element. | ||||
<OutputConstraints> := <ModulationTypeList><FECTypeList> | ||||
5.3. Compatibility and Capability Details | ||||
5.3.1. Modulation Type List | ||||
Modulation type, also known as optical tributary signal class, | ||||
comes in two distinct flavors: (i) ITU-T standardized types; (ii) | ||||
vendor specific types. The permitted modulation type list can | ||||
include any mixture of standardized and vendor specific types. | ||||
<modulation-list>::= | ||||
[<STANDARD_MODULATION>|<VENDOR_MODULATION>]... | ||||
Where the STANDARD_MODULATION object just represents one of the | ||||
ITU-T standardized optical tributary signal class and the | ||||
VENDOR_MODULATION object identifies one vendor specific modulation | ||||
type. | ||||
5.3.2. FEC Type List | ||||
Some devices can handle more than one FEC type and hence a list is | ||||
needed. | ||||
<fec-list>::= [<FEC>] | ||||
Where the FEC object represents one of the ITU-T standardized FECs | ||||
defined in [G.709], [G.707], [G.975.1] or a vendor-specific FEC. | ||||
5.3.3. Bit Rate Range List | ||||
Some devices can handle more than one particular bit rate range | ||||
and hence a list is needed. | ||||
<rate-range-list>::= [<rate-range>]... | ||||
<rate-range>::=<START_RATE><END_RATE> | ||||
Where the START_RATE object represents the lower end of the range | ||||
and the END_RATE object represents the higher end of the range. | ||||
5.3.4. Acceptable Client Signal List | ||||
The list is simply: | ||||
<client-signal-list>::=[<GPID>]... | ||||
Where the Generalized Protocol Identifiers (GPID) object | ||||
represents one of the IETF standardized GPID values as defined in | ||||
[RFC3471] and [RFC4328]. | ||||
5.3.5. Processing Capability List | ||||
We have defined ProcessingCapabilities in Section 5.2 as follows: | ||||
<ProcessingCapabilities> ::= | ||||
<RegenerationCapabilities><FaultPerfMon><VendorSpecific> | ||||
The processing capability list sub-TLV is a list of processing | ||||
functions that the WSON network element (NE) can perform on the | ||||
signal including: | ||||
1. Regeneration capability | ||||
2. Fault and performance monitoring | ||||
3. Vendor Specific capability | ||||
Note that the code points for Fault and performance monitoring and | ||||
vendor specific capability are subject to further study. | ||||
6. Link Information (General) | ||||
MPLS-TE routing protocol extensions for OSPF and IS-IS [RFC3630], | MPLS-TE routing protocol extensions for OSPF and IS-IS [RFC3630], | |||
[RFC5305] along with GMPLS routing protocol extensions for OSPF and | [RFC5305] along with GMPLS routing protocol extensions for OSPF and | |||
IS-IS [RFC4203, RFC5307] provide the bulk of the relatively static | IS-IS [RFC4203, RFC5307] provide the bulk of the relatively static | |||
link information needed by the RWA process. WSON networks bring in | link information needed by the RWA process. However, WSON networks | |||
additional link related constraints. These stem from WDM line system | bring in additional link related constraints. These stem from WDM | |||
characterization, laser transmitter tuning restrictions, and | line system characterization, laser transmitter tuning restrictions, | |||
switching subsystem port wavelength constraints, e.g., colored ROADM | and switching subsystem port wavelength constraints, e.g., colored | |||
drop ports. | ROADM drop ports. | |||
In the following summarize both information from existing route | In the following summarize both information from existing GMPLS route | |||
protocols and new information that maybe needed by the RWA process. | protocols and new information that maybe needed by the RWA process. | |||
<LinkInfo> ::= <LinkID> [<AdministrativeGroup>] [<InterfaceCapDesc>] | <LinkInfo> ::= <LinkID> [<AdministrativeGroup>] [<InterfaceCapDesc>] | |||
[<Protection>] [<SRLG>]... [<TrafficEngineeringMetric>] | [<Protection>] [<SRLG>]... [<TrafficEngineeringMetric>] | |||
[<PortWavelengthRestriction>] | [<PortLabelRestriction>] | |||
3.3.1. Administrative Group | 6.1. Administrative Group | |||
AdministrativeGroup: Defined in [RFC3630]. Each set bit corresponds | AdministrativeGroup: Defined in [RFC3630]. Each set bit corresponds | |||
to one administrative group assigned to the interface. A link may | to one administrative group assigned to the interface. A link may | |||
belong to multiple groups. This is a configured quantity and can be | belong to multiple groups. This is a configured quantity and can be | |||
used to influence routing decisions. | used to influence routing decisions. | |||
3.3.2. Interface Switching Capability Descriptor | 6.2. Interface Switching Capability Descriptor | |||
InterfaceSwCapDesc: Defined in [RFC4202], lets us know the different | InterfaceSwCapDesc: Defined in [RFC4202], lets us know the different | |||
switching capabilities on this GMPLS interface. In both [RFC4203] and | switching capabilities on this GMPLS interface. In both [RFC4203] and | |||
[RFC5307] this information gets combined with the maximum LSP | [RFC5307] this information gets combined with the maximum LSP | |||
bandwidth that can be used on this link at eight different priority | bandwidth that can be used on this link at eight different priority | |||
levels. | levels. | |||
3.3.3. Link Protection Type (for this link) | 6.3. Link Protection Type (for this link) | |||
Protection: Defined in [RFC4202] and implemented in [RFC4203, | Protection: Defined in [RFC4202] and implemented in [RFC4203, | |||
RFC5307]. Used to indicate what protection, if any, is guarding this | RFC5307]. Used to indicate what protection, if any, is guarding this | |||
link. | link. | |||
3.3.4. Shared Risk Link Group Information | 6.4. Shared Risk Link Group Information | |||
SRLG: Defined in [RFC4202] and implemented in [RFC4203, RFC5307]. | SRLG: Defined in [RFC4202] and implemented in [RFC4203, RFC5307]. | |||
This allows for the grouping of links into shared risk groups, i.e., | This allows for the grouping of links into shared risk groups, i.e., | |||
those links that are likely, for some reason, to fail at the same | those links that are likely, for some reason, to fail at the same | |||
time. | time. | |||
3.3.5. Traffic Engineering Metric | 6.5. Traffic Engineering Metric | |||
TrafficEngineeringMetric: Defined in [RFC3630]. This allows for the | TrafficEngineeringMetric: Defined in [RFC3630]. This allows for the | |||
definition of one additional link metric value for traffic | definition of one additional link metric value for traffic | |||
engineering separate from the IP link state routing protocols link | engineering separate from the IP link state routing protocols link | |||
metric. Note that multiple "link metric values" could find use in | metric. Note that multiple "link metric values" could find use in | |||
optical networks, however it would be more useful to the RWA process | optical networks, however it would be more useful to the RWA process | |||
to assign these specific meanings such as link mile metric, or | to assign these specific meanings such as link mile metric, or | |||
probability of failure metric, etc... | probability of failure metric, etc... | |||
3.3.6. Port Wavelength (label) Restrictions | 6.6. Port Label (Wavelength) Restrictions | |||
Port wavelength (label) restrictions (PortWavelengthRestriction) | Port label (wavelength) restrictions (PortLabelRestriction) model the | |||
model the wavelength (label) restrictions that the link and various | label (wavelength) restrictions that the link and various optical | |||
optical devices such as OXCs, ROADMs, and waveband multiplexers may | devices such as OXCs, ROADMs, and waveband multiplexers may impose on | |||
impose on a port. These restrictions tell us what wavelength may or | a port. These restrictions tell us what wavelength may or may not be | |||
may not be used on a link and are relatively static. This plays an | used on a link and are relatively static. This plays an important | |||
important role in fully characterizing a WSON switching device | role in fully characterizing a WSON switching device [Switch]. Port | |||
[Switch]. Port wavelength restrictions are specified relative to the | wavelength restrictions are specified relative to the port in general | |||
port in general or to a specific connectivity matrix (section 3.2.1. | or to a specific connectivity matrix (section 4.1. Reference | |||
Reference [Switch] gives an example where both switch and fixed | [Switch] gives an example where both switch and fixed connectivity | |||
connectivity matrices are used and both types of constraints occur on | matrices are used and both types of constraints occur on the same | |||
the same port. Such restrictions could be applied generally to other | port. Such restrictions could be applied generally to other label | |||
label types in GMPLS by adding new kinds of restrictions. | types in GMPLS by adding new kinds of restrictions. | |||
<PortWavelengthRestriction> ::= [<GeneralPortRestrictions>...] | <PortLabelRestriction> ::= [<GeneralPortRestrictions>...] | |||
[<MatrixSpecificRestrictions>...] | [<MatrixSpecificRestrictions>...] | |||
<GeneralPortRestrictions> ::= <RestrictionType> | <GeneralPortRestrictions> ::= <RestrictionType> | |||
[<RestrictionParameters>] | [<RestrictionParameters>] | |||
<MatrixSpecificRestriction> ::= <MatrixID> <RestrictionType> | <MatrixSpecificRestriction> ::= <MatrixID> <RestrictionType> | |||
[<RestrictionParameters>] | [<RestrictionParameters>] | |||
<RestrictionParameters> ::= [<WavelengthSet>...] [<MaxNumChannels>] | <RestrictionParameters> ::= [<LabelSet>...] [<MaxNumChannels>] | |||
[<MaxWaveBandWidth>] | [<MaxWaveBandWidth>] | |||
Where | Where | |||
MatrixID is the ID of the corresponding connectivity matrix (section | MatrixID is the ID of the corresponding connectivity matrix (section | |||
3.2.1. | 4.1. | |||
The RestrictionType parameter is used to specify general port | The RestrictionType parameter is used to specify general port | |||
restrictions and matrix specific restrictions. It can take the | restrictions and matrix specific restrictions. It can take the | |||
following values and meanings: | following values and meanings: | |||
SIMPLE_WAVELENGTH: Simple wavelength set restriction; The | SIMPLE_WAVELENGTH: Simple wavelength set restriction; The | |||
wavelength set parameter is required. | wavelength set parameter is required. | |||
CHANNEL_COUNT: The number of channels is restricted to be less than | CHANNEL_COUNT: The number of channels is restricted to be less than | |||
or equal to the Max number of channels parameter (which is required). | or equal to the Max number of channels parameter (which is required). | |||
skipping to change at page 12, line 41 | skipping to change at page 15, line 38 | |||
of channels. Note that an additional wavelength set can be used to | of channels. Note that an additional wavelength set can be used to | |||
indicate the overall tuning range. Specific center frequency tuning | indicate the overall tuning range. Specific center frequency tuning | |||
information can be obtained from dynamic channel in use information. | information can be obtained from dynamic channel in use information. | |||
It is assumed that both center frequency and bandwidth (Q) tuning can | It is assumed that both center frequency and bandwidth (Q) tuning can | |||
be done without causing faults in existing signals. | be done without causing faults in existing signals. | |||
Restriction specific parameters are used with one or more of the | Restriction specific parameters are used with one or more of the | |||
previously listed restriction types. The currently defined parameters | previously listed restriction types. The currently defined parameters | |||
are: | are: | |||
WavelengthSet is a conceptual set of wavelengths (labels). | LabelSet is a conceptual set of labels (wavelengths). | |||
MaxNumChannels is the maximum number of channels that can be | MaxNumChannels is the maximum number of channels that can be | |||
simultaneously used (relative to either a port or a matrix). | simultaneously used (relative to either a port or a matrix). | |||
MaxWaveBandWidth is the maximum width of a tunable waveband switching | MaxWaveBandWidth is the maximum width of a tunable waveband | |||
device. | switching device. | |||
For example, if the port is a "colored" drop port of a ROADM then we | For example, if the port is a "colored" drop port of a ROADM then we | |||
have two restrictions: (a) CHANNEL_COUNT, with MaxNumChannels = 1, | have two restrictions: (a) CHANNEL_COUNT, with MaxNumChannels = 1, | |||
and (b) SIMPLE_WAVELENGTH, with the wavelength set consisting of a | and (b) SIMPLE_WAVELENGTH, with the wavelength set consisting of a | |||
single member corresponding to the frequency of the permitted | single member corresponding to the frequency of the permitted | |||
wavelength. See [Switch] for a complete waveband example. | wavelength. See [Switch] for a complete waveband example. | |||
This information model for port wavelength (label) restrictions is | This information model for port wavelength (label) restrictions is | |||
fairly general in that it can be applied to ports that have label | fairly general in that it can be applied to ports that have label | |||
restrictions only or to ports that are part of an asymmetric switch | restrictions only or to ports that are part of an asymmetric switch | |||
and have label restrictions. In addition, the types of label | and have label restrictions. In addition, the types of label | |||
restrictions that can be supported are extensible. | restrictions that can be supported are extensible. | |||
3.4. Dynamic Link Information | 7. Dynamic Components of the Information Model | |||
By dynamic information we mean information that is subject to change | In the previously presented information model there are a limited | |||
on a link with subsequent connection establishment or teardown. | number of information elements that are dynamic, i.e., subject to | |||
Currently for WSON the only information we currently envision is | change with subsequent establishment and teardown of connections. | |||
wavelength availability and wavelength in use for shared backup | Depending on the protocol used to convey this overall information | |||
purposes. | model it may be possible to send this dynamic information separate | |||
from the relatively larger amount of static information needed to | ||||
characterize WSON's and their network elements. | ||||
<DynamicLinkInfo> ::= <LinkID> <AvailableWavelengths> | 7.1. Dynamic Link Information (General) | |||
[<SharedBackupWavelengths>] | ||||
AvailableWavelengths is a set of wavelengths (labels) currently | For WSON links wavelength availability and wavelengths in use for | |||
available on the link. Given this information and the port wavelength | shared backup purposes can be considered dynamic information and | |||
hence we can isolate the dynamic information in the following set: | ||||
<DynamicLinkInfo> ::= <LinkID> <AvailableLabels> | ||||
[<SharedBackupLabels>] | ||||
AvailableLabels is a set of labels (wavelengths) currently available | ||||
on the link. Given this information and the port wavelength | ||||
restrictions we can also determine which wavelengths are currently in | restrictions we can also determine which wavelengths are currently in | |||
use. This parameter could potential be used with other technologies | use. This parameter could potential be used with other technologies | |||
that GMPLS currently covers or may cover in the future. | that GMPLS currently covers or may cover in the future. | |||
SharedBackupWavelengths is a set of wavelengths (labels)currently | SharedBackupLabels is a set of labels (wavelengths)currently used for | |||
used for shared backup protection on the link. An example usage of | shared backup protection on the link. An example usage of this | |||
this information in a WSON setting is given in [Shared]. This | information in a WSON setting is given in [Shared]. This parameter | |||
parameter could potential be used with other technologies that GMPLS | could potential be used with other technologies that GMPLS currently | |||
currently covers or may cover in the future. | covers or may cover in the future. | |||
3.5. Dynamic Node Information | ||||
Dynamic node information is used to hold information for a node that | 7.2. Dynamic Node Information (WSON Specific) | |||
can change frequently. Currently only wavelength converter pool | ||||
information is included as a possible (but not required) information | ||||
sub-element. | ||||
<DynamicNodeInfo> ::= <NodeID> [<WavelengthConverterPoolStatus>] | Currently the only node information that can be considered dynamic is | |||
the resource pool state and can be isolated into a dynamic node | ||||
information element as follows: | ||||
Where NodeID is a node identifier and the exact form of the | <DynamicNodeInfo> ::= <NodeID> [<ResourcePoolState>] | |||
wavelength converter pool status information is TBD. | ||||
4. Security Considerations | 8. Security Considerations | |||
This document discussed an information model for RWA computation in | This document discussed an information model for RWA computation in | |||
WSONs. Such a model is very similar from a security standpoint of the | WSONs. Such a model is very similar from a security standpoint of the | |||
information that can be currently conveyed via GMPLS routing | information that can be currently conveyed via GMPLS routing | |||
protocols. Such information includes network topology, link state | protocols. Such information includes network topology, link state | |||
and current utilization, and well as the capabilities of switches and | and current utilization, and well as the capabilities of switches and | |||
routers within the network. As such this information should be | routers within the network. As such this information should be | |||
protected from disclosure to unintended recipients. In addition, the | protected from disclosure to unintended recipients. In addition, the | |||
intentional modification of this information can significantly affect | intentional modification of this information can significantly affect | |||
network operations, particularly due to the large capacity of the | network operations, particularly due to the large capacity of the | |||
optical infrastructure to be controlled. | optical infrastructure to be controlled. | |||
5. IANA Considerations | 9. IANA Considerations | |||
This informational document does not make any requests for IANA | This informational document does not make any requests for IANA | |||
action. | action. | |||
6. Acknowledgments | 10. Acknowledgments | |||
This document was prepared using 2-Word-v2.0.template.dot. | This document was prepared using 2-Word-v2.0.template.dot. | |||
7. References | 11. References | |||
7.1. Normative References | 11.1. Normative References | |||
[Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and | [Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and | |||
Wavelength Assignment Information Encoding for Wavelength | Wavelength Assignment Information Encoding for Wavelength | |||
Switched Optical Networks", work in progress: draft-ietf- | Switched Optical Networks", work in progress: draft-ietf- | |||
ccamp-rwa-wson-encode. | ccamp-rwa-wson-encode. | |||
[G.707] ITU-T Recommendation G.707, Network node interface for the | ||||
synchronous digital hierarchy (SDH), January 2007. | ||||
[G.709] ITU-T Recommendation G.709, Interfaces for the Optical | ||||
Transport Network(OTN), March 2003. | ||||
[G.975.1] ITU-T Recommendation G.975.1, Forward error correction for | ||||
high bit-rate DWDM submarine systems, February 2004. | ||||
[RBNF] A. Farrel, "Reduced Backus-Naur Form (RBNF) A Syntax Used in | [RBNF] A. Farrel, "Reduced Backus-Naur Form (RBNF) A Syntax Used in | |||
Various Protocol Specifications", RFC 5511, April 2009. | Various Protocol Specifications", RFC 5511, April 2009. | |||
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label | ||||
Switching (GMPLS) Signaling Functional Description", RFC | ||||
3471, January 2003. | ||||
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering | [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering | |||
(TE) Extensions to OSPF Version 2", RFC 3630, September | (TE) Extensions to OSPF Version 2", RFC 3630, September | |||
2003. | 2003. | |||
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions | [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions | |||
in Support of Generalized Multi-Protocol Label Switching | in Support of Generalized Multi-Protocol Label Switching | |||
(GMPLS)", RFC 4202, October 2005 | (GMPLS)", RFC 4202, October 2005 | |||
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in | [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in | |||
Support of Generalized Multi-Protocol Label Switching | Support of Generalized Multi-Protocol Label Switching | |||
(GMPLS)", RFC 4203, October 2005. | (GMPLS)", RFC 4203, October 2005. | |||
[RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label | ||||
Switching (GMPLS) Signaling Extensions for G.709 Optical | ||||
Transport Networks Control", RFC 4328, January 2006. | ||||
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic | [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic | |||
Engineering", RFC 5305, October 2008. | Engineering", RFC 5305, October 2008. | |||
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions | [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions | |||
in Support of Generalized Multi-Protocol Label Switching | in Support of Generalized Multi-Protocol Label Switching | |||
(GMPLS)", RFC 5307, October 2008. | (GMPLS)", RFC 5307, October 2008. | |||
[WSON-Frame] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS | [WSON-Frame] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS | |||
and PCE Control of Wavelength Switched Optical Networks", | and PCE Control of Wavelength Switched Optical Networks", | |||
work in progress: draft-ietf-ccamp-rwa-wson-framework. | work in progress: draft-ietf-ccamp-rwa-wson-framework. | |||
7.2. Informative References | 11.2. Informative References | |||
[Shared] G. Bernstein, Y. Lee, "Shared Backup Mesh Protection in PCE- | [Shared] G. Bernstein, Y. Lee, "Shared Backup Mesh Protection in PCE- | |||
based WSON Networks", iPOP 2008, http://www.grotto- | based WSON Networks", iPOP 2008, http://www.grotto- | |||
networking.com/wson/iPOP2008_WSON-shared-mesh-poster.pdf . | networking.com/wson/iPOP2008_WSON-shared-mesh-poster.pdf . | |||
[Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling | [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling | |||
WDM Wavelength Switching Systems for Use in GMPLS and Automated | WDM Wavelength Switching Systems for Use in GMPLS and Automated | |||
Path Computation", Journal of Optical Communications and | Path Computation", Journal of Optical Communications and | |||
Networking, vol. 1, June, 2009, pp. 187-195. | Networking, vol. 1, June, 2009, pp. 187-195. | |||
[G.Sup39] ITU-T Series G Supplement 39, Optical system design and | [G.Sup39] ITU-T Series G Supplement 39, Optical system design and | |||
engineering considerations, February 2006. | engineering considerations, February 2006. | |||
[WC-Pool] G. Bernstein, Y. Lee, "Modeling WDM Switching Systems | [WC-Pool] G. Bernstein, Y. Lee, "Modeling WDM Switching Systems | |||
including Wavelength Converters" to appear www.grotto- | including Wavelength Converters" to appear www.grotto- | |||
networking.com, 2008. | networking.com, 2008. | |||
8. Contributors | 12. Contributors | |||
Diego Caviglia | Diego Caviglia | |||
Ericsson | Ericsson | |||
Via A. Negrone 1/A 16153 | Via A. Negrone 1/A 16153 | |||
Genoa Italy | Genoa Italy | |||
Phone: +39 010 600 3736 | Phone: +39 010 600 3736 | |||
Email: diego.caviglia@(marconi.com, ericsson.com) | Email: diego.caviglia@(marconi.com, ericsson.com) | |||
Anders Gavler | Anders Gavler | |||
End of changes. 79 change blocks. | ||||
204 lines changed or deleted | 373 lines changed or added | |||
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |