< draft-ietf-ccamp-rwa-info-22.txt | draft-ietf-ccamp-rwa-info-23.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: February 2015 Grotto Networking | Expires: February 2015 Grotto Networking | |||
D. Li | D. Li | |||
Huawei | Huawei | |||
W. Imajuku | W. Imajuku | |||
NTT | NTT | |||
August 18, 2014 | November 6, 2014 | |||
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-22.txt | draft-ietf-ccamp-rwa-info-23.txt | |||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted to IETF in full conformance with | This Internet-Draft is submitted to IETF in full conformance with | |||
the provisions of BCP 78 and BCP 79. | the 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 | |||
months and may be updated, replaced, or obsoleted by other documents | months and may be updated, replaced, or obsoleted by other documents | |||
at any time. It is inappropriate to use Internet-Drafts as | at any time. It is inappropriate to use Internet-Drafts as | |||
reference material or to cite them other than as "work in progress." | reference 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 February 18, 2015. | This Internet-Draft will expire on February 6, 2015. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2014 IETF Trust and the persons identified as the | Copyright (c) 2014 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 | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 40 | skipping to change at page 2, line 40 | |||
2. Terminology....................................................3 | 2. Terminology....................................................3 | |||
3. Routing and Wavelength Assignment Information Model............4 | 3. Routing and Wavelength Assignment Information Model............4 | |||
3.1. Dynamic and Relatively Static Information.................4 | 3.1. Dynamic and Relatively Static Information.................4 | |||
4. Node Information (General).....................................4 | 4. Node Information (General).....................................4 | |||
4.1. Connectivity Matrix.......................................5 | 4.1. Connectivity Matrix.......................................5 | |||
5. Node Information (WSON specific)...............................6 | 5. Node Information (WSON specific)...............................6 | |||
5.1. Resource Accessibility/Availability.......................7 | 5.1. Resource Accessibility/Availability.......................7 | |||
5.2. Resource Signal Constraints and Processing Capabilities..11 | 5.2. Resource Signal Constraints and Processing Capabilities..11 | |||
5.3. Compatibility and Capability Details.....................12 | 5.3. Compatibility and Capability Details.....................12 | |||
5.3.1. Shared Input or Output Indication...................12 | 5.3.1. Shared Input or Output Indication...................12 | |||
5.3.2. Optical Interface Class List........................12 | 5.3.2. Optical Interface Class List........................13 | |||
5.3.3. Acceptable Client Signal List.......................12 | 5.3.3. Acceptable Client Signal List.......................13 | |||
5.3.4. Processing Capability List..........................13 | 5.3.4. Processing Capability List..........................13 | |||
6. Link Information (General)....................................13 | 6. Link Information (General)....................................14 | |||
6.1. Administrative Group.....................................14 | 6.1. Administrative Group.....................................14 | |||
6.2. Interface Switching Capability Descriptor................14 | 6.2. Interface Switching Capability Descriptor................15 | |||
6.3. Link Protection Type (for this link).....................14 | 6.3. Link Protection Type (for this link).....................15 | |||
6.4. Shared Risk Link Group Information.......................14 | 6.4. Shared Risk Link Group Information.......................15 | |||
6.5. Traffic Engineering Metric...............................14 | 6.5. Traffic Engineering Metric...............................15 | |||
6.6. Port Label Restrictions..................................14 | 6.6. Port Label Restrictions..................................15 | |||
6.6.1. Port-Wavelength Exclusivity Example.................17 | 6.6.1. Port-Wavelength Exclusivity Example.................18 | |||
7. Dynamic Components of the Information Model...................18 | 7. Dynamic Components of the Information Model...................19 | |||
7.1. Dynamic Link Information (General).......................19 | 7.1. Dynamic Link Information (General).......................20 | |||
7.2. Dynamic Node Information (WSON Specific).................19 | 7.2. Dynamic Node Information (WSON Specific).................20 | |||
8. Security Considerations.......................................19 | 8. Security Considerations.......................................20 | |||
9. IANA Considerations...........................................20 | 9. IANA Considerations...........................................21 | |||
10. Acknowledgments..............................................20 | 10. Acknowledgments..............................................21 | |||
11. References...................................................21 | 11. References...................................................22 | |||
11.1. Normative References....................................21 | 11.1. Normative References....................................22 | |||
11.2. Informative References..................................22 | 11.2. Informative References..................................23 | |||
12. Contributors.................................................23 | 12. Contributors.................................................24 | |||
Author's Addresses...............................................24 | Authors' Addresses...............................................25 | |||
Intellectual Property Statement..................................24 | Intellectual Property Statement..................................25 | |||
Disclaimer of Validity...........................................25 | Disclaimer of Validity...........................................26 | |||
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. This | general purpose network management information model. This | |||
constraint is frequently referred to as the "wavelength continuity" | constraint is frequently referred to as the "wavelength continuity" | |||
constraint, and the corresponding constrained lightpath computation | constraint, and the corresponding constrained lightpath computation | |||
is known as the routing and wavelength assignment (RWA) problem. | is known as the routing and wavelength assignment (RWA) problem. | |||
Hence the information model must provide sufficient topology and | Hence the information model must provide sufficient topology and | |||
skipping to change at page 5, line 47 | skipping to change at page 5, line 47 | |||
conceptual M by N matrix representing the potential switched or | conceptual M by N matrix representing the potential switched or | |||
fixed connectivity, where M represents the number of input ports and | fixed connectivity, where M represents the number of input ports and | |||
N the number of output ports. This is a "conceptual" matrix since | N the number of output ports. This is a "conceptual" matrix since | |||
the matrix tends to exhibit structure that allows for very compact | the matrix tends to exhibit structure that allows for very compact | |||
representations that are useful for both transmission and path | representations that are useful for both transmission and path | |||
computation. | computation. | |||
Note that the connectivity matrix information element can be useful | Note that the connectivity matrix information element can be useful | |||
in any technology context where asymmetric switches are utilized. | in any technology context where asymmetric switches are utilized. | |||
<ConnectivityMatrix> ::= <MatrixID> <ConnType> <Matrix> | <ConnectivityMatrix> ::= <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 switched. | connectivity is either fixed or 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 input port i can connect | Matrix(i, j) = 0 or 1 depending on whether input port i can connect | |||
to output port j for one or more wavelengths. | to output port j for one or more wavelengths. | |||
5. Node Information (WSON specific) | 5. Node Information (WSON specific) | |||
skipping to change at page 7, line 5 | skipping to change at page 7, line 9 | |||
devices, e.g., on line cards or other types of modules, the | devices, e.g., on line cards or other types of modules, the | |||
fundamental unit of identifiable resource in this document is the | fundamental unit of identifiable resource in this document is the | |||
"resource block". A resource block may contain one or more | "resource block". A resource block may contain one or more | |||
resources. A resource is the smallest identifiable unit of | resources. A resource is the smallest identifiable unit of | |||
processing allocation. One can group together resources into blocks | processing allocation. One can group together resources into blocks | |||
if they have similar characteristics relevant to the optical system | if they have similar characteristics relevant to the optical system | |||
being modeled, e.g., processing properties, accessibility, etc. | being modeled, e.g., processing properties, accessibility, etc. | |||
This leads to the following formal high level model: | This leads to the following formal high level model: | |||
<Node_Information> ::= <Node_ID> [<ConnectivityMatrix>...] | <Node_Information> ::= <Node_ID> | |||
[<ConnectivityMatrix>...] | ||||
[<ResourcePool>] | [<ResourcePool>] | |||
Where | Where | |||
<ResourcePool> ::= <ResourceBlockInfo>... | <ResourcePool> ::= <ResourceBlockInfo>... | |||
[<ResourceAccessibility>...] [<ResourceWaveConstraints>...] | ||||
[<ResourceAccessibility>...] | ||||
[<ResourceWaveConstraints>...] | ||||
[<RBPoolState>] | [<RBPoolState>] | |||
First the accessibility of resource blocks is addressed then their | First the accessibility of resource blocks is addressed then their | |||
properties are discussed. | properties are discussed. | |||
5.1. Resource Accessibility/Availability | 5.1. Resource Accessibility/Availability | |||
A similar technique as used to model ROADMs and optical switches can | A similar technique as used to model ROADMs and optical switches can | |||
be used to model regenerator/converter accessibility. This technique | be used to model regenerator/converter accessibility. This technique | |||
was generally discussed in [RFC6163] and consisted of a matrix to | was generally discussed in [RFC6163] and consisted of a matrix to | |||
skipping to change at page 9, line 31 | skipping to change at page 9, line 31 | |||
+-------------+ ^ ^ +-------------+ | +-------------+ ^ ^ +-------------+ | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
Input wavelength Output wavelength | Input wavelength Output wavelength | |||
constraints for constraints for | constraints for constraints for | |||
each resource each resource | each resource each resource | |||
Note: Rb is a Resource Block. | ||||
Figure 1 Schematic diagram of resource pool model. | Figure 1 Schematic diagram of resource pool model. | |||
I1 +-------------+ +-------------+ O1 | I1 +-------------+ +-------------+ O1 | |||
----->| | +--------+ | |-----> | ----->| | +--------+ | |-----> | |||
I2 | +======+ Rb #1 +-+ + | O2 | I2 | +======+ Rb #1 +-+ | | O2 | |||
----->| | +--------+ | | |-----> | ----->| | +--------+ | | |-----> | |||
| | |=====| | | | | |=====| | | |||
| Resource | +--------+ | | Resource | | | Resource | +--------+ | | Resource | | |||
| Pool | +-+ Rb #2 +-+ | Pool | | | Pool | +-+ Rb #2 +-+ | Pool | | |||
| | | +--------+ + | | | | | +--------+ | | | |||
| Input |====| | Output | | | Input |====| | Output | | |||
| Connection | | +--------+ | Connection | | | Connection | | +--------+ | Connection | | |||
| Matrix | +-| Rb #3 |=======| Matrix | | | Matrix | +-| Rb #3 |=======| Matrix | | |||
| | +--------+ | | | | | +--------+ | | | |||
| | . | | | | | . | | | |||
| | . | | | | | . | | | |||
| | . | | | | | . | | | |||
IN | | +--------+ | | OM | IN | | +--------+ | | OM | |||
----->| +======+ Rb #P +=======+ |-----> | ----->| +======+ Rb #P +=======+ |-----> | |||
| | +--------+ | | | | | +--------+ | | | |||
+-------------+ ^ ^ +-------------+ | +-------------+ ^ ^ +-------------+ | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
Single (shared) fibers for block input and output | Single (shared) fibers for block input and output | |||
Input wavelength Output wavelength | Input wavelength Output wavelength | |||
availability for availability for | availability for availability for | |||
each block input fiber each block output fiber | each block input fiber each block output fiber | |||
Note: Rb is a Resource Block. | ||||
Figure 2 Schematic diagram of resource pool model with shared block | Figure 2 Schematic diagram of resource pool model with shared block | |||
accessibility. | accessibility. | |||
Formally the model can be specified as: | Formally the model can be specified as: | |||
<ResourceAccessibility ::= <PoolInputMatrix> <PoolOutputMatrix> | <ResourceAccessibility> ::= <PoolInputMatrix> | |||
<PoolOutputMatrix> | ||||
<ResourceWaveConstraints> ::= <InputWaveConstraints> | <ResourceWaveConstraints> ::= <InputWaveConstraints> | |||
<OutputOutputWaveConstraints> | <OutputOutputWaveConstraints> | |||
<RBSharedAccessWaveAvailability> ::= [<InAvailableWavelengths>] | <RBSharedAccessWaveAvailability> ::= [<InAvailableWavelengths>] | |||
[<OutAvailableWavelengths>] | [<OutAvailableWavelengths>] | |||
<RBPoolState> ::=<ResourceBlockID> <NumResourcesInUse> | ||||
[<RBSharedAccessWaveAvailability>] [<RBPoolState>] | <RBPoolState> ::= <ResourceBlockID> | |||
<NumResourcesInUse> | ||||
[<RBSharedAccessWaveAvailability>] | ||||
[<RBPoolState>] | ||||
Note that except for <RBPoolState> all the other components of | Note that except for <RBPoolState> all the other components of | |||
<ResourcePool> are relatively static. Also the | <ResourcePool> are relatively static. Also the | |||
<InAvailableWavelengths> and <OutAvailableWavelengths> are only used | <InAvailableWavelengths> and <OutAvailableWavelengths> are only used | |||
in the cases of shared input or output access to the particular | in the cases of shared input or output access to the particular | |||
block. See the resource block information in the next section to see | block. See the resource block information in the next section to see | |||
how this is specified. | how this is specified. | |||
5.2. Resource Signal Constraints and Processing Capabilities | 5.2. Resource Signal Constraints and Processing Capabilities | |||
The wavelength conversion abilities of a resource (e.g. regenerator, | The wavelength conversion abilities of a resource (e.g. regenerator, | |||
wavelength converter) were modeled in the <OutputWaveConstraints> | wavelength converter) were modeled in the <OutputWaveConstraints> | |||
previously discussed. As discussed in [RFC6163] the constraints on | previously discussed. As discussed in [RFC6163] the constraints on | |||
an electro-optical resource can be modeled in terms of input | an electro-optical resource can be modeled in terms of input | |||
constraints, processing capabilities, and output constraints: | constraints, processing capabilities, and output constraints: | |||
<ResourceBlockInfo> ::= <ResourceBlockSet> [<InputConstraints>] | <ResourceBlockInfo> ::= <ResourceBlockSet> | |||
[<ProcessingCapabilities>] [<OutputConstraints>] | ||||
[<InputConstraints>] | ||||
[<ProcessingCapabilities>] | ||||
[<OutputConstraints>] | ||||
Where <ResourceBlockSet> is a list of resource block identifiers | Where <ResourceBlockSet> is a list of resource block identifiers | |||
with the same characteristics. If this set is missing the | with the same characteristics. If this set is missing the | |||
constraints are applied to the entire network element. | constraints are applied to the entire network element. | |||
The <InputConstraints> are signal compatibility based constraints | The <InputConstraints> are signal compatibility based constraints | |||
and/or shared access constraint indication. The details of these | and/or shared access constraint indication. The details of these | |||
constraints are defined in section 5.3. | constraints are defined in section 5.3. | |||
<InputConstraints> ::= <SharedInput> [<OpticalInterfaceClassList>] | <InputConstraints> ::= <SharedInput> | |||
[<OpticalInterfaceClassList>] | ||||
[<ClientSignalList>] | [<ClientSignalList>] | |||
The <ProcessingCapabilities> are important operations that the | The <ProcessingCapabilities> are important operations that the | |||
resource (or network element) can perform on the signal. The details | resource (or network element) can perform on the signal. The details | |||
of these capabilities are defined in section 5.3. | of these capabilities are defined in section 5.3. | |||
<ProcessingCapabilities> ::= [<NumResources>] | <ProcessingCapabilities> ::= [<NumResources>] | |||
[<RegenerationCapabilities>] [<FaultPerfMon>] [<VendorSpecific>] | ||||
[<RegenerationCapabilities>] | ||||
[<FaultPerfMon>] | ||||
[<VendorSpecific>] | ||||
The <OutputConstraints> are either restrictions on the properties of | The <OutputConstraints> are either restrictions on the properties of | |||
the signal leaving the block, options concerning the signal | the signal leaving the block, options concerning the signal | |||
properties when leaving the resource or shared fiber output | properties when leaving the resource or shared fiber output | |||
constraint indication. | constraint indication. | |||
<OutputConstraints> := <SharedOutput> | <OutputConstraints> := <SharedOutput> | |||
[<OpticalInterfaceClassList>][<ClientSignalList>] | ||||
[<OpticalInterfaceClassList>] | ||||
[<ClientSignalList>] | ||||
5.3. Compatibility and Capability Details | 5.3. Compatibility and Capability Details | |||
5.3.1. Shared Input or Output Indication | 5.3.1. Shared Input or Output Indication | |||
As discussed in the previous section and shown in Figure 2 the input | As discussed in the previous section and shown in Figure 2 the input | |||
or output access to a resource block may be via a shared fiber. The | or output access to a resource block may be via a shared fiber. The | |||
<SharedInput> and <SharedOutput> elements are indicators for this | <SharedInput> and <SharedOutput> elements are indicators for this | |||
condition with respect to the block being described. | condition with respect to the block being described. | |||
5.3.2. Optical Interface Class List | 5.3.2. Optical Interface Class List | |||
<OpticalInterfaceClassList> ::= <OpticalInterfaceClass> ... | <OpticalInterfaceClassList> ::= <OpticalInterfaceClass> ... | |||
The Optical Interface Class is a unique number that identifies | The Optical Interface Class is a unique number that identifies | |||
all information related to optical characteristics of a physical | all information related to optical characteristics of a physical | |||
interface. The class may include other optical parameters | interface. The class may include other optical parameters | |||
related to other interface properties. A class always includes | related to other interface properties. A class always includes | |||
signal compatibility information. | signal compatibility information. | |||
The content of each class is out of the scope of this draft and | The content of each class is out of the scope of this document | |||
can be defined by other entities (e.g. ITU, optical equipment | and can be defined by other entities (e.g. ITU, optical | |||
vendors, etc.). | equipment vendors, etc.). | |||
Since even current implementation of physical interfaces may | Since even current implementation of physical interfaces may | |||
support different optical characteristics, a single interface may | support different optical characteristics, a single interface may | |||
support multiple interface classes. Which optical interface | support multiple interface classes. Which optical interface | |||
class is used among all the ones available for an interface is | class is used among all the ones available for an interface is | |||
out of the scope of this draft but is an output of the RWA | out of the scope of this document but is an output of the RWA | |||
process. | process. | |||
5.3.3. Acceptable Client Signal List | 5.3.3. Acceptable Client Signal List | |||
The list is simply: | The list is simply: | |||
< ClientSignalList>::=[<G-PID>]... | < ClientSignalList>::=[<G-PID>]... | |||
Where the Generalized Protocol Identifiers (G-PID) object | Where the Generalized Protocol Identifiers (G-PID) object | |||
represents one of the IETF standardized G-PID values as defined | represents one of the IETF standardized G-PID values as defined | |||
skipping to change at page 13, line 39 | skipping to change at page 14, line 23 | |||
link information needed by the RWA process. However, WSON networks | link information needed by the RWA process. However, WSON networks | |||
bring in additional link related constraints. These stem from WDM | bring in additional link related constraints. These stem from WDM | |||
line system characterization, laser transmitter tuning restrictions, | line system characterization, laser transmitter tuning restrictions, | |||
and switching subsystem port wavelength constraints, e.g., colored | and switching subsystem port wavelength constraints, e.g., colored | |||
ROADM drop ports. | ROADM drop ports. | |||
In the following summarize both information from existing GMPLS | In the following summarize both information from existing GMPLS | |||
route protocols and new information that maybe needed by the RWA | route protocols and new information that maybe needed by the RWA | |||
process. | process. | |||
<LinkInfo> ::= <LinkID> [<AdministrativeGroup>] | <LinkInfo> ::= <LinkID> | |||
[<InterfaceCapDesc>] [<Protection>] [<SRLG>...] | ||||
[<TrafficEngineeringMetric>] [<PortLabelRestriction>...] | [<AdministrativeGroup>] | |||
[<InterfaceCapDesc>] | ||||
[<Protection>] | ||||
[<SRLG>...] | ||||
[<TrafficEngineeringMetric>] | ||||
[<PortLabelRestriction>...] | ||||
Note that these additional link characteristics only applies to line | Note that these additional link characteristics only applies to line | |||
side ports of WDM system or add/drop ports pertaining to Resource | side ports of WDM system or add/drop ports pertaining to Resource | |||
Pool (e.g., Regenerator or Wavelength Converter Pool). The | Pool (e.g., Regenerator or Wavelength Converter Pool). The | |||
advertisement of input/output tributary ports is not intended here. | advertisement of input/output tributary ports is not intended here. | |||
6.1. Administrative Group | 6.1. Administrative Group | |||
AdministrativeGroup: Defined in [RFC3630]. Each set bit corresponds | AdministrativeGroup: Defined in [RFC3630] and extended for MPLS-TE | |||
to one administrative group assigned to the interface. A link may | [RFC7308]. Each set bit corresponds to one administrative group | |||
belong to multiple groups. This is a configured quantity and can be | assigned to the interface. A link may belong to multiple groups. | |||
used to influence routing decisions. | This is a configured quantity and can be used to influence routing | |||
decisions. | ||||
6.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] | switching capabilities on this GMPLS interface. In both [RFC4203] | |||
and [RFC5307] this information gets combined with the maximum LSP | and [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. | |||
6.3. Link Protection Type (for this link) | 6.3. Link Protection Type (for this link) | |||
skipping to change at page 14, line 35 | skipping to change at page 15, line 28 | |||
6.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. | |||
6.5. Traffic Engineering Metric | 6.5. Traffic Engineering Metric | |||
TrafficEngineeringMetric: Defined in [RFC3630]. This allows for the | TrafficEngineeringMetric: Defined in [RFC3630] and [RFC5305]. This | |||
identification of a data channel link metric value for traffic | allows for the identification of a data channel link metric value | |||
engineering that is separate from the metric used for path cost | for traffic engineering that is separate from the metric used for | |||
computation of the control plane. | path cost computation of the control plane. | |||
Note that multiple "link metric values" could find use in optical | Note that multiple "link metric values" could find use in optical | |||
networks, however it would be more useful to the RWA process to | networks, however it would be more useful to the RWA process to | |||
assign these specific meanings such as link mile metric, or | assign these specific meanings such as link mile metric, or | |||
probability of failure metric, etc... | probability of failure metric, etc... | |||
6.6. Port Label Restrictions | 6.6. Port Label Restrictions | |||
Port label restrictions could be applied generally to any label | Port label restrictions could be applied generally to any label | |||
types in GMPLS by adding new kinds of restrictions. Wavelength is a | types in GMPLS by adding new kinds of restrictions. Wavelength is a | |||
skipping to change at page 15, line 15 | skipping to change at page 16, line 7 | |||
Port label (wavelength) restrictions (PortLabelRestriction) model | Port label (wavelength) restrictions (PortLabelRestriction) model | |||
the label (wavelength) restrictions that the link and various | the label (wavelength) restrictions that the link and various | |||
optical devices such as OXCs, ROADMs, and waveband multiplexers may | optical devices such as OXCs, ROADMs, and waveband multiplexers may | |||
impose on a port. These restrictions tell us what wavelength may or | impose on a port. These restrictions tell us what wavelength may or | |||
may not be used on a link and are relatively static. This plays an | may not be used on a link and are relatively static. This plays an | |||
important role in fully characterizing a WSON switching device | important role in fully characterizing a WSON switching device | |||
[Switch]. Port wavelength restrictions are specified relative to the | [Switch]. Port wavelength restrictions are specified relative to the | |||
port in general or to a specific connectivity matrix (section 4.1. | port in general or to a specific connectivity matrix (section 4.1. | |||
Reference [Switch] gives an example where both switch and fixed | Reference [Switch] gives an example where both switch and fixed | |||
connectivity matrices are used and both types of constraints occur | connectivity matrices are used and both types of constraints occur | |||
on the same port. <PortLabelRestriction> ::= <MatrixID> | on the same port. | |||
<PortLabelRestriction> ::= <MatrixID> | ||||
<RestrictionType> | <RestrictionType> | |||
<Restriction parameters list> | <Restriction parameters list> | |||
<Restriction parameters list> ::= | <Restriction parameters list> ::= | |||
<Simple label restriction parameters> | | <Simple label restriction parameters> | | |||
<Channel count restriction parameters> | | <Channel count restriction parameters> | | |||
<Label range restriction parameters> | | <Label range restriction parameters> | | |||
<Simple+channel restriction parameters> | | <Simple+channel restriction parameters> | | |||
<Exclusive label restriction parameters> | <Exclusive label restriction parameters> | |||
<Simple label restriction parameters> ::= <LabelSet> ... | <Simple label restriction parameters> ::= <LabelSet> ... | |||
<Channel count restriction parameters> ::= <MaxNumChannels> | <Channel count restriction parameters> ::= <MaxNumChannels> | |||
<Label range restriction parameters> ::= | <Label range restriction parameters> ::= <MaxLabelRange> | |||
<MaxLabelRange> (<LabelSet> ...) | ||||
<Simple+channel restriction parameters> ::= | (<LabelSet> ...) | |||
<MaxNumChannels> (<LabelSet> ...) | ||||
<Simple+channel restriction parameters> ::= <MaxNumChannels> | ||||
(<LabelSet> ...) | ||||
<Exclusive label restriction parameters> ::= <LabelSet> ... | <Exclusive label restriction parameters> ::= <LabelSet> ... | |||
Where | Where | |||
MatrixID is the ID of the corresponding connectivity matrix (section | MatrixID is the ID of the corresponding connectivity matrix (section | |||
4.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 | |||
skipping to change at page 16, line 43 | skipping to change at page 18, line 10 | |||
previously listed restriction types. The currently defined | previously listed restriction types. The currently defined | |||
parameters are: | parameters are: | |||
LabelSet is a conceptual set of labels (wavelengths). | 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). | |||
LinkSet is a conceptual set of ports. | LinkSet is a conceptual set of ports. | |||
MaxLabelRange indicates the maximum range of the labels.For example, | MaxLabelRange indicates the maximum range of the labels. For | |||
if the port is a "colored" drop port of a ROADM then there are two | example, if the port is a "colored" drop port of a ROADM then there | |||
restrictions: (a) CHANNEL_COUNT, with MaxNumChannels = 1, and (b) | are two restrictions: (a) CHANNEL_COUNT, with MaxNumChannels = 1, | |||
SIMPLE_WAVELENGTH, with the wavelength set consisting of a single | and (b) SIMPLE_WAVELENGTH, with the wavelength set consisting of a | |||
member corresponding to the frequency of the permitted wavelength. | single member corresponding to the frequency of the permitted | |||
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. | |||
6.6.1. Port-Wavelength Exclusivity Example | 6.6.1. Port-Wavelength Exclusivity Example | |||
Although there can be many different ROADM or switch architectures | Although there can be many different ROADM or switch architectures | |||
skipping to change at page 19, line 11 | skipping to change at page 20, line 11 | |||
model it may be possible to send this dynamic information separate | model it may be possible to send this dynamic information separate | |||
from the relatively larger amount of static information needed to | from the relatively larger amount of static information needed to | |||
characterize WSON's and their network elements. | characterize WSON's and their network elements. | |||
7.1. Dynamic Link Information (General) | 7.1. Dynamic Link Information (General) | |||
For WSON links wavelength availability and wavelengths in use for | For WSON links wavelength availability and wavelengths in use for | |||
shared backup purposes can be considered dynamic information and | shared backup purposes can be considered dynamic information and | |||
hence are grouped with the dynamic information in the following set: | hence are grouped with the dynamic information in the following set: | |||
<DynamicLinkInfo> ::= <LinkID> <AvailableLabels> | <DynamicLinkInfo> ::= <LinkID> | |||
<AvailableLabels> | ||||
[<SharedBackupLabels>] | [<SharedBackupLabels>] | |||
AvailableLabels is a set of labels (wavelengths) currently available | AvailableLabels is a set of labels (wavelengths) currently available | |||
on the link. Given this information and the port wavelength | on the link. Given this information and the port wavelength | |||
restrictions one can also determine which wavelengths are currently | restrictions one can also determine which wavelengths are currently | |||
in use. This parameter could potential be used with other | in use. This parameter could potential be used with other | |||
technologies that GMPLS currently covers or may cover in the future. | technologies that GMPLS currently covers or may cover in the future. | |||
SharedBackupLabels is a set of labels (wavelengths) currently used | SharedBackupLabels is a set of labels (wavelengths) currently used | |||
for shared backup protection on the link. An example usage of this | for shared backup protection on the link. An example usage of this | |||
skipping to change at page 21, line 9 | skipping to change at page 22, line 9 | |||
action. | action. | |||
10. 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. | |||
11. References | 11. References | |||
11.1. Normative References | 11.1. Normative References | |||
[G.707] ITU-T Recommendation G.707, Network node interface for the | [G.7715] ITU-T Recommendation G.7715, Architecture and requirements | |||
synchronous digital hierarchy (SDH), January 2007. | for routing in the automatically switched optical | |||
networks, June 2002. | ||||
[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 | [RBNF] A. Farrel, "Reduced Backus- | |||
in Various Protocol Specifications", RFC 5511, April 2009. | Naur Form (RBNF) A Syntax Used in Various Protocol | |||
Specifications", RFC 5511, April 2009. | ||||
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label | [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label | |||
Switching (GMPLS) Signaling Functional Description", RFC | Switching (GMPLS) Signaling Functional Description", RFC | |||
3471, January 2003. | 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. | |||
[RFC5305] T. Li, and H. SMIT, "Intermediate System to Intermediate | ||||
System (IS-IS) Extensions for Traffic Engineering (TE)", | ||||
RFC 5305, October 2008. | ||||
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing | [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing | |||
Extensions in Support of Generalized Multi-Protocol Label | Extensions in Support of Generalized Multi-Protocol Label | |||
Switching (GMPLS)", RFC 4202, October 2005 | Switching (GMPLS)", RFC 4202, October 2005 | |||
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions | [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions | |||
in Support of Generalized Multi-Protocol Label Switching | in 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 | [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label | |||
Switching (GMPLS) Signaling Extensions for G.709 Optical | Switching (GMPLS) Signaling Extensions for G.709 Optical | |||
Transport Networks Control", RFC 4328, January 2006. | Transport Networks Control", RFC 4328, January 2006. | |||
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic | ||||
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. | |||
[RFC7308] E. Osborne, "Extended Administrative Groups in MPLS | ||||
Traffic Engineering (MPLS-TE)", RFC 7308, July 2014. | ||||
11.2. Informative References | 11.2. Informative References | |||
[OFC08] P. Roorda and B. Collings, "Evolution to Colorless and | [OFC08] P. Roorda and B. Collings, "Evolution to Colorless and | |||
Directionless ROADM Architectures," Optical Fiber | Directionless ROADM Architectures," Optical Fiber | |||
communication/National Fiber Optic Engineers Conference, | communication/National Fiber Optic Engineers Conference, | |||
2008. OFC/NFOEC 2008. Conference on, 2008, pp. 1-3. | 2008. OFC/NFOEC 2008. Conference on, 2008, pp. 1-3. | |||
[Shared] G. Bernstein, Y. Lee, "Shared Backup Mesh Protection in | [Shared] G. Bernstein, Y. Lee, "Shared Backup Mesh Protection in | |||
PCE-based WSON Networks", iPOP 2008. | PCE-based WSON Networks", iPOP 2008. | |||
[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 | WDM Wavelength Switching Systems for Use in GMPLS and | |||
Automated Path Computation", Journal of Optical | Automated Path Computation", Journal of Optical | |||
Communications and Networking, vol. 1, June, 2009, pp. | Communications and Networking, vol. 1, June, 2009, pp. | |||
187-195. | 187-195. | |||
[G.Sup39] ITU-T Series G Supplement 39, Optical system design and | ||||
engineering considerations, February 2006. | ||||
[RFC5920] L. Fang, Ed., "Security Framework for MPLS and GMPLS | [RFC5920] L. Fang, Ed., "Security Framework for MPLS and GMPLS | |||
Networks", RFC 5920, July 2010. | Networks", RFC 5920, July 2010. | |||
[RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS and | [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS and | |||
PCE Control of Wavelength Switched Optical Networks", RFC | PCE Control of Wavelength Switched Optical Networks", RFC | |||
6163, April 2011. | 6163, April 2011. | |||
12. Contributors | 12. Contributors | |||
Diego Caviglia | Diego Caviglia | |||
skipping to change at page 24, line 5 | skipping to change at page 25, line 5 | |||
Phone: +81 44 396 3287 | Phone: +81 44 396 3287 | |||
Email: i-nishioka@cb.jp.nec.com | Email: i-nishioka@cb.jp.nec.com | |||
Lyndon Ong | Lyndon Ong | |||
Ciena | Ciena | |||
Email: lyong@ciena.com | Email: lyong@ciena.com | |||
Cyril Margaria | Cyril Margaria | |||
Email: cyril.margaria@gmail.com | Email: cyril.margaria@gmail.com | |||
Author's Addresses | Authors' Addresses | |||
Greg M. Bernstein (ed.) | Greg M. Bernstein (ed.) | |||
Grotto Networking | Grotto Networking | |||
Fremont California, USA | Fremont California, USA | |||
Phone: (510) 573-2237 | Phone: (510) 573-2237 | |||
Email: gregb@grotto-networking.com | Email: gregb@grotto-networking.com | |||
Young Lee (ed.) | Young Lee (ed.) | |||
Huawei Technologies | Huawei Technologies | |||
End of changes. 45 change blocks. | ||||
82 lines changed or deleted | 145 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |