| < draft-ietf-ccamp-rwa-info-12.txt | draft-ietf-ccamp-rwa-info-13.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: March 2012 Grotto Networking | Expires: April 2012 Grotto Networking | |||
| D. Li | D. Li | |||
| Huawei | Huawei | |||
| W. Imajuku | W. Imajuku | |||
| NTT | NTT | |||
| September 9, 2011 | October 31, 2011 | |||
| 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-12.txt | draft-ietf-ccamp-rwa-info-13.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 | |||
| 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. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six | |||
| and may be updated, replaced, or obsoleted by other documents at any | months and may be updated, replaced, or obsoleted by other documents | |||
| time. It is inappropriate to use Internet-Drafts as reference | at any time. It is inappropriate to use Internet-Drafts as | |||
| 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 March 9, 2012. | This Internet-Draft will expire on March 31, 2012. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2011 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 | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with | |||
| to this document. Code Components extracted from this document must | respect to this document. Code Components extracted from this | |||
| include Simplified BSD License text as described in Section 4.e of | document must include Simplified BSD License text as described in | |||
| the Trust Legal Provisions and are provided without warranty as | Section 4.e of the Trust Legal Provisions and are provided without | |||
| described in the Simplified BSD License. | 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. This model takes into account compatibility constraints | WSONs. This model takes into account compatibility constraints | |||
| between WSON signal attributes and network elements but does not | between WSON signal attributes and network elements but does not | |||
| include constraints due to optical impairments. Aspects of this | include constraints due to optical impairments. Aspects of this | |||
| skipping to change at page 2, line 42 ¶ | skipping to change at page 2, line 42 ¶ | |||
| 1.1.2. Changes from 02......................................4 | 1.1.2. Changes from 02......................................4 | |||
| 1.1.3. Changes from 03......................................5 | 1.1.3. Changes from 03......................................5 | |||
| 1.1.4. Changes from 04......................................5 | 1.1.4. Changes from 04......................................5 | |||
| 1.1.5. Changes from 05......................................5 | 1.1.5. Changes from 05......................................5 | |||
| 1.1.6. Changes from 06......................................5 | 1.1.6. Changes from 06......................................5 | |||
| 1.1.7. Changes from 07......................................5 | 1.1.7. Changes from 07......................................5 | |||
| 1.1.8. Changes from 08......................................5 | 1.1.8. Changes from 08......................................5 | |||
| 1.1.9. Changes from 09......................................5 | 1.1.9. Changes from 09......................................5 | |||
| 1.1.10. Changes from 10.....................................6 | 1.1.10. Changes from 10.....................................6 | |||
| 1.1.11. Changes from 11.....................................6 | 1.1.11. Changes from 11.....................................6 | |||
| 1.1.12. Changes from 12.....................................6 | ||||
| 2. Terminology....................................................6 | 2. Terminology....................................................6 | |||
| 3. Routing and Wavelength Assignment Information Model............7 | 3. Routing and Wavelength Assignment Information Model............7 | |||
| 3.1. Dynamic and Relatively Static Information.................7 | 3.1. Dynamic and Relatively Static Information.................7 | |||
| 4. Node Information (General).....................................7 | 4. Node Information (General).....................................8 | |||
| 4.1. Connectivity Matrix.......................................8 | 4.1. Connectivity Matrix.......................................8 | |||
| 4.2. Shared Risk Node Group....................................9 | 4.2. Shared Risk Node Group....................................9 | |||
| 5. Node Information (WSON specific)...............................9 | 5. Node Information (WSON specific)...............................9 | |||
| 5.1. Resource Accessibility/Availability......................10 | 5.1. Resource Accessibility/Availability......................10 | |||
| 5.2. Resource Signal Constraints and Processing Capabilities..14 | 5.2. Resource Signal Constraints and Processing Capabilities..14 | |||
| 5.3. Compatibility and Capability Details.....................15 | 5.3. Compatibility and Capability Details.....................15 | |||
| 5.3.1. Shared Input or Output Indication...................15 | 5.3.1. Shared Input or Output Indication...................15 | |||
| 5.3.2. Modulation Type List................................15 | 5.3.2. Modulation Type List................................15 | |||
| 5.3.3. FEC Type List.......................................15 | 5.3.3. FEC Type List.......................................15 | |||
| 5.3.4. Bit Rate Range List.................................15 | 5.3.4. Bit Rate Range List.................................15 | |||
| 5.3.5. Acceptable Client Signal List.......................16 | 5.3.5. Acceptable Client Signal List.......................16 | |||
| 5.3.6. Processing Capability List..........................16 | 5.3.6. Processing Capability List..........................16 | |||
| 6. Link Information (General)....................................16 | 6. Link Information (General)....................................16 | |||
| 6.1. Administrative Group.....................................17 | 6.1. Administrative Group.....................................17 | |||
| 6.2. Interface Switching Capability Descriptor................17 | 6.2. Interface Switching Capability Descriptor................17 | |||
| 6.3. Link Protection Type (for this link).....................17 | 6.3. Link Protection Type (for this link).....................17 | |||
| 6.4. Shared Risk Link Group Information.......................17 | 6.4. Shared Risk Link Group Information.......................17 | |||
| 6.5. Traffic Engineering Metric...............................17 | 6.5. Traffic Engineering Metric...............................17 | |||
| 6.6. Port Label (Wavelength) Restrictions.....................17 | 6.6. Port Label (Wavelength) Restrictions.....................18 | |||
| 6.6.1. Port-Wavelength Exclusivity Example.................19 | 6.6.1. Port-Wavelength Exclusivity Example.................19 | |||
| 7. Dynamic Components of the Information Model...................20 | 7. Dynamic Components of the Information Model...................21 | |||
| 7.1. Dynamic Link Information (General).......................21 | 7.1. Dynamic Link Information (General).......................21 | |||
| 7.2. Dynamic Node Information (WSON Specific).................21 | 7.2. Dynamic Node Information (WSON Specific).................21 | |||
| 8. Security Considerations.......................................21 | 8. Security Considerations.......................................21 | |||
| 9. IANA Considerations...........................................22 | 9. IANA Considerations...........................................22 | |||
| 10. Acknowledgments..............................................22 | 10. Acknowledgments..............................................22 | |||
| 11. References...................................................23 | 11. References...................................................23 | |||
| 11.1. Normative References....................................23 | 11.1. Normative References....................................23 | |||
| 11.2. Informative References..................................24 | 11.2. Informative References..................................24 | |||
| 12. Contributors.................................................25 | 12. Contributors.................................................25 | |||
| Author's Addresses...............................................25 | Author's Addresses...............................................26 | |||
| Intellectual Property Statement..................................26 | Intellectual Property Statement..................................26 | |||
| Disclaimer of Validity...........................................27 | Disclaimer of Validity...........................................27 | |||
| 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 constraint | general purpose network management information model. This | |||
| is frequently referred to as the "wavelength continuity" constraint, | constraint is frequently referred to as the "wavelength continuity" | |||
| and the corresponding constrained lightpath computation is known as | constraint, and the corresponding constrained lightpath computation | |||
| the routing and wavelength assignment (RWA) problem. Hence the | is known as the routing and wavelength assignment (RWA) problem. | |||
| information model must provide sufficient topology and wavelength | Hence the information model must provide sufficient topology and | |||
| restriction and availability information to support this computation. | wavelength restriction and availability information to support this | |||
| More details on the RWA process and WSON subsystems and their | computation. More details on the RWA process and WSON subsystems and | |||
| properties can be found in [RFC6163]. The model defined here includes | their properties can be found in [RFC6163]. The model defined here | |||
| constraints between WSON signal attributes and network elements, but | includes constraints between WSON signal attributes and network | |||
| does not include optical impairments. | elements, but does not include optical impairments. | |||
| In addition to presenting an information model suitable for path | In addition to presenting an information model suitable for path | |||
| computation in WSON, this document also highlights model aspects that | computation in WSON, this document also highlights model aspects | |||
| may have general applicability to other technologies utilizing a | that may have general applicability to other technologies utilizing | |||
| GMPLS control plane. The portion of the information model applicable | a GMPLS control plane. The portion of the information model | |||
| to other technologies beyond WSON is referred to as "general" to | applicable to other technologies beyond WSON is referred to as | |||
| distinguish it from the "WSON-specific" portion that is applicable | "general" to distinguish it from the "WSON-specific" portion that is | |||
| only to WSON technology. | applicable only to WSON technology. | |||
| 1.1. Revision History | 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. | |||
| Added clarifying text on wavelength availability information and how | Added clarifying text on wavelength availability information and how | |||
| to derive wavelengths currently in use. | to derive wavelengths currently in use. | |||
| 1.1.2. Changes from 02 | 1.1.2. Changes from 02 | |||
| Integrated switched and fixed connectivity matrices into a single | Integrated switched and fixed connectivity matrices into a single | |||
| "connectivity matrix" model. Added numbering of matrices to allow for | "connectivity matrix" model. Added numbering of matrices to allow | |||
| wavelength (time slot, label) dependence of the connectivity. | for wavelength (time slot, label) dependence of the connectivity. | |||
| Discussed general use of this node parameter beyond WSON. | Discussed general use of this node parameter beyond WSON. | |||
| Integrated switched and fixed port wavelength restrictions into a | Integrated switched and fixed port wavelength restrictions into a | |||
| single port wavelength restriction of which there can be more than | single port wavelength restriction of which there can be more than | |||
| one and added a reference to the corresponding connectivity matrix if | one and added a reference to the corresponding connectivity matrix | |||
| there is one. Also took into account port wavelength restrictions in | if there is one. Also took into account port wavelength restrictions | |||
| the case of symmetric switches, developed a uniform model and | in the case of symmetric switches, developed a uniform model and | |||
| specified how general label restrictions could be taken into account | specified how general label restrictions could be taken into account | |||
| with this model. | with this model. | |||
| Removed the Shared Risk Node Group parameter from the node info, but | Removed the Shared Risk Node Group parameter from the node info, but | |||
| left explanation of how the same functionality can be achieved with | left explanation of how the same functionality can be achieved with | |||
| existing GMPLS SRLG constructs. | existing GMPLS SRLG constructs. | |||
| Removed Maximum bandwidth per channel parameter from link | Removed Maximum bandwidth per channel parameter from link | |||
| information. | information. | |||
| skipping to change at page 5, line 31 ¶ | skipping to change at page 5, line 31 ¶ | |||
| Updated abstract and introduction to encompass signal | Updated abstract and introduction to encompass signal | |||
| compatibility/generalization. | compatibility/generalization. | |||
| Generalized Section on wavelength converter pools to include electro | Generalized Section on wavelength converter pools to include electro | |||
| optical subsystems in general. This is where signal compatibility | optical subsystems in general. This is where signal compatibility | |||
| modeling was added. | modeling was added. | |||
| 1.1.6. Changes from 06 | 1.1.6. Changes from 06 | |||
| Simplified information model for WSON specifics, by combining similar | Simplified information model for WSON specifics, by combining | |||
| fields and introducing simpler aggregate information elements. | similar fields and introducing simpler aggregate information | |||
| elements. | ||||
| 1.1.7. Changes from 07 | 1.1.7. Changes from 07 | |||
| Added shared fiber connectivity to resource pool modeling. This | Added shared fiber connectivity to resource pool modeling. This | |||
| includes information for determining wavelength collision on an | includes information for determining wavelength collision on an | |||
| internal fiber providing access to resource blocks. | internal fiber providing access to resource blocks. | |||
| 1.1.8. Changes from 08 | 1.1.8. Changes from 08 | |||
| Added PORT_WAVELENGTH_EXCLUSIVITY in the RestrictionType parameter. | Added PORT_WAVELENGTH_EXCLUSIVITY in the RestrictionType parameter. | |||
| skipping to change at page 6, line 20 ¶ | skipping to change at page 6, line 20 ¶ | |||
| 1.1.10. Changes from 10 | 1.1.10. Changes from 10 | |||
| Enhanced the explanation of shared fiber access to resources and | Enhanced the explanation of shared fiber access to resources and | |||
| updated Figure 2 to show a more general situation to be modeled. | updated Figure 2 to show a more general situation to be modeled. | |||
| Removed all 1st person idioms. | Removed all 1st person idioms. | |||
| 1.1.11. Changes from 11 | 1.1.11. Changes from 11 | |||
| Replace all instances of "ingress" with "input" and all instances of | Replace all instances of "ingress" with "input" and all instances of | |||
| "egress" with "output". Added clarifying text on relationship between | "egress" with "output". Added clarifying text on relationship | |||
| resource block model and physical entities such as line cards. | between resource block model and physical entities such as line | |||
| cards. | ||||
| 1.1.12. Changes from 12 | ||||
| Section 5.2: Clarified RBNF optional elements for several | ||||
| definitions. | ||||
| Section 5.3.6: Clarified RBNF optional elements for | ||||
| <ProcessingCapabilities>. | ||||
| Editorial changes for clarity. | ||||
| Update the contributor list. | ||||
| 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 input and | count wavelength selective switching element featuring input and | |||
| output line side ports as well as add/drop side ports. | output line side ports as well as add/drop side ports. | |||
| RWA: Routing and Wavelength Assignment. | RWA: Routing and Wavelength Assignment. | |||
| Wavelength Conversion. The process of converting an information | Wavelength Conversion. The process of converting an information | |||
| bearing optical signal centered at a given wavelength to one with | bearing optical signal centered at a given wavelength to one with | |||
| "equivalent" content centered at a different wavelength. Wavelength | "equivalent" content centered at a different wavelength. Wavelength | |||
| conversion can be implemented via an optical-electronic-optical (OEO) | conversion can be implemented via an optical-electronic-optical | |||
| process or via a strictly optical process. | (OEO) process or via a strictly optical process. | |||
| WDM: Wavelength Division Multiplexing. | WDM: Wavelength Division Multiplexing. | |||
| Wavelength Switched Optical Network (WSON): A WDM based optical | Wavelength Switched Optical Network (WSON): A WDM based optical | |||
| network in which switching is performed selectively based on the | network in which switching is performed selectively based on the | |||
| center wavelength of an optical signal. | center wavelength of an optical signal. | |||
| 3. Routing and Wavelength Assignment Information Model | 3. Routing and Wavelength Assignment Information Model | |||
| The following WSON RWA information model is grouped into four | The following WSON RWA information model is grouped into four | |||
| categories regardless of whether they stem from a switching subsystem | categories regardless of whether they stem from a switching | |||
| or from a line subsystem: | subsystem or from a line subsystem: | |||
| o Node Information | o Node Information | |||
| 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] | |||
| 7. | section 7. | |||
| In the following, where applicable, the reduced Backus-Naur form | In the following, where applicable, the reduced Backus-Naur form | |||
| (RBNF) syntax of [RBNF] is used to aid in defining the RWA | (RBNF) syntax of [RBNF] is used to aid in defining the RWA | |||
| information model. | 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 | |||
| and this information is a key input to the RWA process. Examples of | setup/teardown and this information is a key input to the RWA | |||
| relatively static information are the potential port connectivity of | process. Examples of relatively static information are the | |||
| a WDM ROADM, and the channel spacing on a WDM link. | potential port connectivity of a WDM ROADM, and the channel spacing | |||
| on a WDM link. | ||||
| This document separates, where possible, dynamic and static | This document separates, 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. | |||
| 4. Node Information (General) | 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 | |||
| include properties of wavelength converters in the node if any are | could include properties of wavelength converters in the node if any | |||
| present. In [Switch] it was shown that the wavelength connectivity | are present. In [Switch] it was shown that the wavelength | |||
| constraints for a large class of practical WSON devices can be | connectivity constraints for a large class of practical WSON devices | |||
| modeled via switched and fixed connectivity matrices along with | can be modeled via switched and fixed connectivity matrices along | |||
| corresponding switched and fixed port constraints. These connectivity | with corresponding switched and fixed port constraints. These | |||
| matrices are included with the node information while the switched | connectivity matrices are included with the node information while | |||
| and fixed port wavelength constraints are included with the link | the switched and fixed port wavelength constraints are included with | |||
| information. | the link information. | |||
| Formally, | Formally, | |||
| <Node_Information> ::= <Node_ID> [<ConnectivityMatrix>...] | <Node_Information> ::= <Node_ID> [<ConnectivityMatrix>...] | |||
| 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]. | |||
| skipping to change at page 8, line 36 ¶ | skipping to change at page 8, line 48 ¶ | |||
| 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 inputinput ports and | internal blocking behavior but indicates which inputinput 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 its highly | is beyond the scope of this document and due to its highly | |||
| implementation dependent nature would most likely not be subject to | implementation dependent nature would most likely not be subject to | |||
| standardization in the future. The connectivity matrix is a | standardization in the future. The connectivity matrix is a | |||
| conceptual M by N matrix representing the potential switched or fixed | conceptual M by N matrix representing the potential switched or | |||
| connectivity, where M represents the number of inputinput ports and N | fixed connectivity, where M represents the number of inputinput | |||
| the number of outputoutput ports. This is a "conceptual" matrix since | ports and N the number of outputoutput ports. This is a "conceptual" | |||
| the matrix tends to exhibit structure that allows for very compact | matrix since the matrix tends to exhibit structure that allows for | |||
| representations that are useful for both transmission and path | very compact representations that are useful for both transmission | |||
| computation [Encode]. | and path computation [Encode]. | |||
| 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 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 inputinput port i can | Matrix(i, j) = 0 or 1 depending on whether inputinput port i can | |||
| connect to outputoutput port j for one or more wavelengths. | connect to outputoutput port j for one or more wavelengths. | |||
| 4.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 | |||
| "amount" of link diversity. It is also desirable to have a similar | desired "amount" of link diversity. It is also desirable to have a | |||
| capability to achieve various degrees of node diversity. This is | similar capability to achieve various degrees of node diversity. | |||
| explained in [G.7715]. Typical risk groupings for nodes can include | This is explained in [G.7715]. Typical risk groupings for nodes can | |||
| those nodes in the same building, within the same city, or geographic | include those nodes in the same building, within the same city, or | |||
| region. | geographic 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. | |||
| 5. Node Information (WSON specific) | 5. Node Information (WSON specific) | |||
| As discussed in [RFC6163] a WSON node may contain electro-optical | As discussed in [RFC6163] a WSON node may contain electro-optical | |||
| subsystems such as regenerators, wavelength converters or entire | subsystems such as regenerators, wavelength converters or entire | |||
| switching subsystems. The model present here can be used in | switching subsystems. The model present here can be used in | |||
| characterizing the accessibility and availability of limited | characterizing the accessibility and availability of limited | |||
| resources such as regenerators or wavelength converters as well as | resources such as regenerators or wavelength converters as well as | |||
| WSON signal attribute constraints of electro-optical subsystems. As | WSON signal attribute constraints of electro-optical subsystems. As | |||
| such this information element is fairly specific to WSON | such this information element is fairly specific to WSON | |||
| technologies. | technologies. | |||
| A WSON node may include regenerators or wavelength converters | A WSON node may include regenerators or wavelength converters | |||
| arranged in a shared pool. As discussed in [RFC6163] this can include | arranged in a shared pool. As discussed in [RFC6163] this can | |||
| OEO based WDM switches as well. There are a number of different | include OEO based WDM switches as well. There are a number of | |||
| approaches used in the design of WDM switches containing regenerator | different approaches used in the design of WDM switches containing | |||
| or converter pools. However, from the point of view of path | regenerator or converter pools. However, from the point of view of | |||
| computation the following need to be known: | path computation the following need to be known: | |||
| 1. The nodes that support regeneration or wavelength conversion. | 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 inputinput wavelength on a particular | convert from a given inputinput wavelength on a particular | |||
| inputinput port to a desired outputoutput wavelength on a | inputinput port to a desired outputoutput wavelength on a | |||
| particular outputoutput port. | particular outputoutput 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. | |||
| Since resources tend to be packaged together in blocks of similar | Since resources tend to be packaged together in blocks of similar | |||
| 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 resources. | "resource block". A resource block may contain one or more | |||
| As resource blocks are the smallest identifiable unit of processing | resources. As resources are the smallest identifiable unit of | |||
| resource, one can group together resources into blocks if they have | processing resource, one can group together resources into blocks if | |||
| similar characteristics relevant to the optical system being modeled, | they have similar characteristics relevant to the optical system | |||
| 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>...] | |||
| skipping to change at page 10, line 39 ¶ | skipping to change at page 10, line 50 ¶ | |||
| 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 | |||
| indicate possible connectivity along with wavelength constraints for | indicate possible connectivity along with wavelength constraints for | |||
| links/ports. Since regenerators or wavelength converters may be | links/ports. Since regenerators or wavelength converters may be | |||
| considered a scarce resource it is desirable that the model include, | considered a scarce resource it is desirable that the model include, | |||
| if desired, the usage state (availability) of individual regenerators | if desired, the usage state (availability) of individual | |||
| or converters in the pool. Models that incorporate more state to | regenerators or converters in the pool. Models that incorporate more | |||
| further reveal blocking conditions on input or output to particular | state to further reveal blocking conditions on input or output to | |||
| converters are for further study and not included here. | particular converters are for further study and not included here. | |||
| The three stage model is shown schematically in Figure 1 and Figure | The three stage model is shown schematically in Figure 1 and Figure | |||
| 2. The difference between the two figures is that Figure 1 assumes | 2. The difference between the two figures is that Figure 1 assumes | |||
| that each signal that can get to a resource block may do so, while in | that each signal that can get to a resource block may do so, while | |||
| Figure 2 the access to sets of resource blocks is via a shared fiber | in Figure 2 the access to sets of resource blocks is via a shared | |||
| which imposes its own wavelength collision constraint. The | fiber which imposes its own wavelength collision constraint. The | |||
| representation of Figure 1 can have more than one input to each | representation of Figure 1 can have more than one input to each | |||
| resource block since each input represents a single wavelength | resource block since each input represents a single wavelength | |||
| signal, while in Figure 2 shows a single multiplexed WDM inputinput | signal, while in Figure 2 shows a single multiplexed WDM inputinput | |||
| or output, e.g., a fiber, to/from each set of block. | or output, e.g., a fiber, to/from each set of block. | |||
| This model assumes N input ports (fibers), P resource blocks | This model assumes N input ports (fibers), P resource blocks | |||
| containing one or more identical resources (e.g. wavelength | containing one or more identical resources (e.g. wavelength | |||
| converters), and M output ports (fibers). Since not all input ports | converters), and M output ports (fibers). Since not all input ports | |||
| can necessarily reach each resource block, the model starts with a | can necessarily reach each resource block, the model starts with a | |||
| resource pool input matrix RI(i,p) = {0,1} whether input port i can | resource pool input matrix RI(i,p) = {0,1} whether input port i can | |||
| reach potentially reach resource block p. | reach potentially reach resource block p. | |||
| Since not all wavelengths can necessarily reach all the resources or | Since not all wavelengths can necessarily reach all the resources or | |||
| the resources may have limited input wavelength range the model has a | the resources may have limited input wavelength range the model has | |||
| set of relatively static input port constraints for each resource. In | a set of relatively static input port constraints for each resource. | |||
| addition, if the access to a set of resource blocks is via a shared | In addition, if the access to a set of resource blocks is via a | |||
| fiber (Figure 2) this would impose a dynamic wavelength availability | shared fiber (Figure 2) this would impose a dynamic wavelength | |||
| constraint on that shared fiber. The resource block input port | availability constraint on that shared fiber. The resource block | |||
| constraint is modeled via a static wavelength set mechanism and the | input port constraint is modeled via a static wavelength set | |||
| case of shared access to a set of blocks is modeled via a dynamic | mechanism and the case of shared access to a set of blocks is | |||
| wavelength set mechanism. | modeled via a dynamic wavelength set mechanism. | |||
| Next a state vector RA(j) = {0,...,k} is used to track the number of | Next a state vector RA(j) = {0,...,k} is used to track the number of | |||
| resources in resource block j in use. This is the only state kept in | resources in resource block j in use. This is the only state kept in | |||
| the resource pool model. This state is not necessary for modeling | the resource pool model. This state is not necessary for modeling | |||
| "fixed" transponder system or full OEO switches with WDM interfaces, | "fixed" transponder system or full OEO switches with WDM interfaces, | |||
| i.e., systems where there is no sharing. | i.e., systems where there is no sharing. | |||
| After that, a set of static resource output wavelength constraints | After that, a set of static resource output wavelength constraints | |||
| and possibly dynamic shared output fiber constraints maybe used. The | and possibly dynamic shared output fiber constraints maybe used. The | |||
| static constraints indicate what wavelengths a particular resource | static constraints indicate what wavelengths a particular resource | |||
| block can generate or are restricted to generating e.g., a fixed | block can generate or are restricted to generating e.g., a fixed | |||
| regenerator would be limited to a single lambda. The dynamic | regenerator would be limited to a single lambda. The dynamic | |||
| constraints would be used in the case where a single shared fiber is | constraints would be used in the case where a single shared fiber is | |||
| used to output the resource block (Figure 2). | used to output the resource block (Figure 2). | |||
| Finally, to complete the model, a resource pool output matrix RE(p,k) | Finally, to complete the model, a resource pool output matrix | |||
| = {0,1} depending on whether the output from resource block p can | RE(p,k) = {0,1} depending on whether the output from resource block | |||
| reach output port k, may be used. | p can reach output port k, may be used. | |||
| I1 +-------------+ +-------------+ E1 | I1 +-------------+ +-------------+ E1 | |||
| ----->| | +--------+ | |-----> | ----->| | +--------+ | |-----> | |||
| I2 | +------+ Rb #1 +-------+ | E2 | I2 | +------+ Rb #1 +-------+ | E2 | |||
| ----->| | +--------+ | |-----> | ----->| | +--------+ | |-----> | |||
| | | | | | | | | | | |||
| | Resource | +--------+ | Resource | | | Resource | +--------+ | Resource | | |||
| | Pool +------+ +-------+ Pool | | | Pool +------+ +-------+ Pool | | |||
| | | + Rb #2 + | | | | | + Rb #2 + | | | |||
| | Input +------+ +-------| Output | | | Input +------+ +-------| Output | | |||
| skipping to change at page 13, line 31 ¶ | skipping to change at page 13, line 31 ¶ | |||
| ----->| +======+ 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 | |||
| 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> | |||
| <RBPoolState> | <RBPoolState> | |||
| ::=(<ResourceBlockID><NumResourcesInUse><InAvailableWavelengths><OutA | ::=(<ResourceBlockID><NumResourcesInUse><InAvailableWavelengths><Out | |||
| vailableWavelengths>)... | AvailableWavelengths>)... | |||
| Note that except for <ResourcePoolState> all the other components of | Note that except for <ResourcePoolState> 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 an | previously discussed. As discussed in [RFC6163] the constraints on | |||
| 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> ::= ([<ResourceSet>] <InputConstraints> | <ResourceBlockInfo> ::= ([<ResourceSet>] <InputConstraints> | |||
| <ProcessingCapabilities> <OutputConstraints>)* | [<ProcessingCapabilities>] <OutputConstraints>)* | |||
| Where <ResourceSet> is a list of resource block identifiers with the | Where <ResourceSet> is a list of resource block identifiers with | |||
| same characteristics. If this set is missing the constraints are | the same characteristics. If this set is missing the constraints are | |||
| applied to the entire network element. | 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> <ModulationTypeList> | <InputConstraints> ::= <SharedInput> [<ModulationTypeList>] | |||
| <FECTypeList> <BitRateRange> <ClientSignalList> | [<FECTypeList>] [<BitRateRange>] [<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> <ModulationTypeList> | <OutputConstraints> := <SharedOutput> [<ModulationTypeList>] | |||
| <FECTypeList> | [<FECTypeList>] | |||
| 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. Modulation Type List | 5.3.2. Modulation Type List | |||
| skipping to change at page 15, line 25 ¶ | skipping to change at page 15, line 25 ¶ | |||
| Modulation type, also known as optical tributary signal class, | Modulation type, also known as optical tributary signal class, | |||
| comes in two distinct flavors: (i) ITU-T standardized types; (ii) | comes in two distinct flavors: (i) ITU-T standardized types; (ii) | |||
| vendor specific types. The permitted modulation type list can | vendor specific types. The permitted modulation type list can | |||
| include any mixture of standardized and vendor specific types. | include any mixture of standardized and vendor specific types. | |||
| <modulation-list>::= | <modulation-list>::= | |||
| [<STANDARD_MODULATION>|<VENDOR_MODULATION>]... | [<STANDARD_MODULATION>|<VENDOR_MODULATION>]... | |||
| Where the STANDARD_MODULATION object just represents one of the | Where the STANDARD_MODULATION object just represents one of the | |||
| ITU-T standardized optical tributary signal class and the | ITU-T standardized optical tributary signal class and the | |||
| VENDOR_MODULATION object identifies one vendor specific modulation | VENDOR_MODULATION object identifies one vendor specific | |||
| type. | modulation type. | |||
| 5.3.3. FEC Type List | 5.3.3. FEC Type List | |||
| Some devices can handle more than one FEC type and hence a list is | Some devices can handle more than one FEC type and hence a list | |||
| needed. | is needed. | |||
| <fec-list>::= [<FEC>] | <fec-list>::= [<FEC>] | |||
| Where the FEC object represents one of the ITU-T standardized FECs | Where the FEC object represents one of the ITU-T standardized | |||
| defined in [G.709], [G.707], [G.975.1] or a vendor-specific FEC. | FECs defined in [G.709], [G.707], [G.975.1] or a vendor-specific | |||
| FEC. | ||||
| 5.3.4. Bit Rate Range List | 5.3.4. Bit Rate Range List | |||
| Some devices can handle more than one particular bit rate range | Some devices can handle more than one particular bit rate range | |||
| and hence a list is needed. | and hence a list is needed. | |||
| <rate-range-list>::= [<rate-range>]... | <rate-range-list>::= [<rate-range>]... | |||
| <rate-range>::=<START_RATE><END_RATE> | <rate-range>::=<START_RATE><END_RATE> | |||
| skipping to change at page 16, line 19 ¶ | skipping to change at page 16, line 19 ¶ | |||
| <client-signal-list>::=[<GPID>]... | <client-signal-list>::=[<GPID>]... | |||
| Where the Generalized Protocol Identifiers (GPID) object | Where the Generalized Protocol Identifiers (GPID) object | |||
| represents one of the IETF standardized GPID values as defined in | represents one of the IETF standardized GPID values as defined in | |||
| [RFC3471] and [RFC4328]. | [RFC3471] and [RFC4328]. | |||
| 5.3.6. Processing Capability List | 5.3.6. Processing Capability List | |||
| The ProcessingCapabilities were defined in Section 5.2 as follows: | The ProcessingCapabilities were defined in Section 5.2 as follows: | |||
| <ProcessingCapabilities> ::= <NumResources> | <ProcessingCapabilities> ::= [<NumResources>] | |||
| <RegenerationCapabilities> <FaultPerfMon> <VendorSpecific> | [<RegenerationCapabilities>] [<FaultPerfMon>] [<VendorSpecific>] | |||
| The processing capability list sub-TLV is a list of processing | The processing capability list sub-TLV is a list of processing | |||
| functions that the WSON network element (NE) can perform on the | functions that the WSON network element (NE) can perform on the | |||
| signal including: | signal including: | |||
| 1. Number of Resources within the block | 1. Number of Resources within the block | |||
| 2. Regeneration capability | 2. Regeneration capability | |||
| 3. Fault and performance monitoring | 3. Fault and performance monitoring | |||
| skipping to change at page 16, line 48 ¶ | skipping to change at page 17, line 5 ¶ | |||
| 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. 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 route | In the following summarize both information from existing GMPLS | |||
| protocols and new information that maybe needed by the RWA process. | route protocols and new information that maybe needed by the RWA | |||
| process. | ||||
| <LinkInfo> ::= <LinkID> [<AdministrativeGroup>] [<InterfaceCapDesc>] | <LinkInfo> ::= <LinkID> [<AdministrativeGroup>] | |||
| [<Protection>] [<SRLG>]... [<TrafficEngineeringMetric>] | [<InterfaceCapDesc>] [<Protection>] [<SRLG>]... | |||
| [<PortLabelRestriction>] | [<TrafficEngineeringMetric>] [<PortLabelRestriction>] | |||
| 6.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. | |||
| 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] and | switching capabilities on this GMPLS interface. In both [RFC4203] | |||
| [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) | |||
| 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. | |||
| 6.4. Shared Risk Link Group Information | 6.4. Shared Risk Link Group Information | |||
| skipping to change at page 17, line 49 ¶ | skipping to change at page 18, line 7 ¶ | |||
| 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... | |||
| 6.6. Port Label (Wavelength) Restrictions | 6.6. Port Label (Wavelength) Restrictions | |||
| Port label (wavelength) restrictions (PortLabelRestriction) model the | Port label (wavelength) restrictions (PortLabelRestriction) model | |||
| label (wavelength) restrictions that the link and various optical | the label (wavelength) restrictions that the link and various | |||
| devices such as OXCs, ROADMs, and waveband multiplexers may impose on | optical devices such as OXCs, ROADMs, and waveband multiplexers may | |||
| a port. These restrictions tell us what wavelength may or may not be | impose on a port. These restrictions tell us what wavelength may or | |||
| used on a link and are relatively static. This plays an important | may not be used on a link and are relatively static. This plays an | |||
| role in fully characterizing a WSON switching device [Switch]. Port | important role in fully characterizing a WSON switching device | |||
| wavelength restrictions are specified relative to the port in general | [Switch]. Port wavelength restrictions are specified relative to the | |||
| or to a specific connectivity matrix (section 4.1. Reference | port in general or to a specific connectivity matrix (section 4.1. | |||
| [Switch] gives an example where both switch and fixed connectivity | Reference [Switch] gives an example where both switch and fixed | |||
| matrices are used and both types of constraints occur on the same | connectivity matrices are used and both types of constraints occur | |||
| port. Such restrictions could be applied generally to other label | on the same port. Such restrictions could be applied generally to | |||
| types in GMPLS by adding new kinds of restrictions. | other label types in GMPLS by adding new kinds of restrictions. | |||
| <PortLabelRestriction> ::= [<GeneralPortRestrictions>...] | <PortLabelRestriction> ::= [<GeneralPortRestrictions>...] | |||
| [<MatrixSpecificRestrictions>...] | [<MatrixSpecificRestrictions>...] | |||
| <GeneralPortRestrictions> ::= <RestrictionType> | <GeneralPortRestrictions> ::= <RestrictionType> | |||
| [<RestrictionParameters>] | [<RestrictionParameters>] | |||
| <MatrixSpecificRestriction> ::= <MatrixID> <RestrictionType> | <MatrixSpecificRestriction> ::= <MatrixID> <RestrictionType> | |||
| [<RestrictionParameters>] | [<RestrictionParameters>] | |||
| skipping to change at page 18, line 39 ¶ | skipping to change at page 18, line 45 ¶ | |||
| 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 | |||
| 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). | ||||
| PORT_WAVELENGTH_EXCLUSIVITY: A wavelength can be used at most once | PORT_WAVELENGTH_EXCLUSIVITY: A wavelength can be used at most once | |||
| among a given set of ports. The set of ports is specified as a | among a given set of ports. The set of ports is specified as a | |||
| parameter to this constraint. | parameter to this constraint. | |||
| WAVEBAND1: Waveband device with a tunable center frequency and | WAVEBAND1: Waveband device with a tunable center frequency and | |||
| passband. This constraint is characterized by the MaxWaveBandWidth | passband. This constraint is characterized by the MaxWaveBandWidth | |||
| parameters which indicates the maximum width of the waveband in terms | parameters which indicates the maximum width of the waveband in | |||
| of channels. Note that an additional wavelength set can be used to | terms of channels. Note that an additional wavelength set can be | |||
| indicate the overall tuning range. Specific center frequency tuning | used to indicate the overall tuning range. Specific center frequency | |||
| information can be obtained from dynamic channel in use information. | tuning information can be obtained from dynamic channel in use | |||
| It is assumed that both center frequency and bandwidth (Q) tuning can | information. It is assumed that both center frequency and bandwidth | |||
| be done without causing faults in existing signals. | (Q) tuning can 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 | |||
| 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). | |||
| MaxWaveBandWidth is the maximum width of a tunable waveband | MaxWaveBandWidth is the maximum width of a tunable waveband | |||
| switching device. | switching device. | |||
| PortSet is a conceptual set of ports. | PortSet is a conceptual set of ports. | |||
| For example, if the port is a "colored" drop port of a ROADM then | For example, if the port is a "colored" drop port of a ROADM then | |||
| there are two restrictions: (a) CHANNEL_COUNT, with MaxNumChannels = | there are two restrictions: (a) CHANNEL_COUNT, with MaxNumChannels = | |||
| 1, and (b) SIMPLE_WAVELENGTH, with the wavelength set consisting of a | 1, and (b) SIMPLE_WAVELENGTH, with the wavelength set consisting of | |||
| single member corresponding to the frequency of the permitted | a 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. | |||
| 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 | |||
| that can lead to the constraint where a lambda (label) maybe used at | that can lead to the constraint where a lambda (label) maybe used at | |||
| most once on a set of ports Figure 3 shows a ROADM architecture based | most once on a set of ports Figure 3 shows a ROADM architecture | |||
| on components known as a Wavelength Selective Switch (WSS)[OFC08]. | based on components known as a Wavelength Selective Switch | |||
| This ROADM is composed of splitters, combiners, and WSSes. This ROADM | (WSS)[OFC08]. This ROADM is composed of splitters, combiners, and | |||
| has 11 output ports, which are numbered in the diagram. Output ports | WSSes. This ROADM has 11 output ports, which are numbered in the | |||
| 1-8 are known as drop ports and are intended to support a single | diagram. Output ports 1-8 are known as drop ports and are intended | |||
| wavelength. Drop ports 1-4 output from WSS #2, which is fed from WSS | to support a single wavelength. Drop ports 1-4 output from WSS #2, | |||
| #1 via a single fiber. Due to this internal structure a constraint is | which is fed from WSS #1 via a single fiber. Due to this internal | |||
| placed on the output ports 1-4 that a lambda can be only used once | structure a constraint is placed on the output ports 1-4 that a | |||
| over the group of ports (assuming uni-cast and not multi-cast | lambda can be only used once over the group of ports (assuming uni- | |||
| operation). Similarly the output ports 5-8 have a similar constraint | cast and not multi-cast operation). Similarly the output ports 5-8 | |||
| due to the internal structure. | have a similar constraint due to the internal structure. | |||
| | A | | A | |||
| v 10 | | v 10 | | |||
| +-------+ +-------+ | +-------+ +-------+ | |||
| | Split | |WSS 6 | | | Split | |WSS 6 | | |||
| +-------+ +-------+ | +-------+ +-------+ | |||
| +----+ | | | | | | | | | +----+ | | | | | | | | | |||
| | W | | | | | | | | +-------+ +----+ | | W | | | | | | | | +-------+ +----+ | |||
| | S |--------------+ | | | +-----+ | +----+ | | S | | | S |--------------+ | | | +-----+ | +----+ | | S | | |||
| 9 | S |----------------|---|----|-------|------|----|---| p | | 9 | S |----------------|---|----|-------|------|----|---| p | | |||
| <--| |----------------|---|----|-------|----+ | +---| l |<-- | <--| |----------------|---|----|-------|----+ | +---| l |<- | |||
| - | ||||
| | 5 |--------------+ | | | +-----+ | | +--| i | | | 5 |--------------+ | | | +-----+ | | +--| i | | |||
| +----+ | | | | | +------|-|-----|--| t | | +----+ | | | | | +------|-|-----|--| t | | |||
| +--------|-+ +----|-|---|------|----+ | +----+ | +--------|-+ +----|-|---|------|----+ | +----+ | |||
| +----+ | | | | | | | | | | +----+ | | | | | | | | | | |||
| | S |-----|--------|----------+ | | | | | | +----+ | | S |-----|--------|----------+ | | | | | | +----+ | |||
| | p |-----|--------|------------|---|------|----|--|--| W | | | p |-----|--------|------------|---|------|----|--|--| W | | |||
| -->| l |-----|-----+ | +----------+ | | | +--|--| S |11 | -->| l |-----|-----+ | +----------+ | | | +--|--| S |11 | |||
| | i |---+ | | | | +------------|------|-------|--| S |--> | | i |---+ | | | | +------------|------|-------|--| S |-- | |||
| > | ||||
| | t | | | | | | | | | | +---|--| | | | t | | | | | | | | | | +---|--| | | |||
| +----+ | | +---|--|-|-|------------|------|-|-|---+ | 7 | | +----+ | | +---|--|-|-|------------|------|-|-|---+ | 7 | | |||
| | | | +--|-|-|--------+ | | | | | +----+ | | | | +--|-|-|--------+ | | | | | +----+ | |||
| | | | | | | | | | | | | | | | | | | | | | | | | | | |||
| +------+ +------+ +------+ +------+ | +------+ +------+ +------+ +------+ | |||
| | WSS 1| | Split| | WSS 3| | Split| | | WSS 1| | Split| | WSS 3| | Split| | |||
| +--+---+ +--+---+ +--+---+ +--+---+ | +--+---+ +--+---+ +--+---+ +--+---+ | |||
| | A | A | | A | A | |||
| v | v | | v | v | | |||
| +-------+ +--+----+ +-------+ +--+----+ | +-------+ +--+----+ +-------+ +--+----+ | |||
| skipping to change at page 21, line 28 ¶ | skipping to change at page 21, line 38 ¶ | |||
| 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 | |||
| information in a WSON setting is given in [Shared]. This parameter | information in a WSON setting is given in [Shared]. This parameter | |||
| could potential be used with other technologies that GMPLS currently | could potential be used with other technologies that GMPLS currently | |||
| covers or may cover in the future. | covers or may cover in the future. | |||
| 7.2. Dynamic Node Information (WSON Specific) | 7.2. Dynamic Node Information (WSON Specific) | |||
| Currently the only node information that can be considered dynamic is | Currently the only node information that can be considered dynamic | |||
| the resource pool state and can be isolated into a dynamic node | is the resource pool state and can be isolated into a dynamic node | |||
| information element as follows: | information element as follows: | |||
| <DynamicNodeInfo> ::= <NodeID> [<ResourcePoolState>] | <DynamicNodeInfo> ::= <NodeID> [<ResourcePoolState>] | |||
| 8. 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 | |||
| information that can be currently conveyed via GMPLS routing | the 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 | |||
| routers within the network. As such this information should be | and 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, | |||
| intentional modification of this information can significantly affect | the intentional modification of this information can significantly | |||
| network operations, particularly due to the large capacity of the | affect network operations, particularly due to the large capacity of | |||
| optical infrastructure to be controlled. | the optical infrastructure to be controlled. | |||
| 9. 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. | |||
| 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. | |||
| skipping to change at page 23, line 23 ¶ | skipping to change at page 23, line 23 ¶ | |||
| [G.707] ITU-T Recommendation G.707, Network node interface for the | [G.707] ITU-T Recommendation G.707, Network node interface for the | |||
| synchronous digital hierarchy (SDH), January 2007. | synchronous digital hierarchy (SDH), January 2007. | |||
| [G.709] ITU-T Recommendation G.709, Interfaces for the Optical | [G.709] ITU-T Recommendation G.709, Interfaces for the Optical | |||
| Transport Network(OTN), March 2003. | Transport Network(OTN), March 2003. | |||
| [G.975.1] ITU-T Recommendation G.975.1, Forward error correction for | [G.975.1] ITU-T Recommendation G.975.1, Forward error correction for | |||
| high bit-rate DWDM submarine systems, February 2004. | 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 | |||
| Various Protocol Specifications", RFC 5511, April 2009. | 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. | |||
| [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions | [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing | |||
| in Support of Generalized Multi-Protocol Label Switching | Extensions in Support of Generalized Multi-Protocol Label | |||
| (GMPLS)", RFC 4202, October 2005 | Switching (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 | |||
| 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 | [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. | |||
| 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 PCE- | [Shared] G. Bernstein, Y. Lee, "Shared Backup Mesh Protection in | |||
| based WSON Networks", iPOP 2008, http://www.grotto- | PCE-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 | 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. 187- | Communications and Networking, vol. 1, June, 2009, pp. | |||
| 195. | 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. | |||
| [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS and | [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS | |||
| PCE Control of Wavelength Switched Optical Networks", RFC | and PCE Control of Wavelength Switched Optical Networks", | |||
| 6163, April 2011. | RFC 6163, April 2011. | |||
| 12. 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) | |||
| skipping to change at page 25, line 41 ¶ | skipping to change at page 25, line 41 ¶ | |||
| 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666 | 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666 | |||
| Japan | Japan | |||
| 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 | ||||
| Nokia Siemens Networks | ||||
| St Martin Strasse 76 | ||||
| Munich, 81541 | ||||
| Germany | ||||
| Phone: +49 89 5159 16934 | ||||
| Email: cyril.margaria@nsn.com | ||||
| Author's Addresses | Author's 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 | |||
| 1700 Alma Drive, Suite 100 | 1700 Alma Drive, Suite 100 | |||
| Plano, TX 75075 | Plano, TX 75075 | |||
| USA | USA | |||
| Phone: (972) 509-5599 (x2240) | Phone: (972) 509-5599 (x2240) | |||
| Email: ylee@huawei.com | Email: ylee@huawei.com | |||
| Dan Li | Dan Li | |||
| skipping to change at page 26, line 44 ¶ | skipping to change at page 27, line 11 ¶ | |||
| claimed to pertain to the implementation or use of the technology | claimed to pertain to the implementation or use of the technology | |||
| described in any IETF Document or the extent to which any license | described in any IETF Document or the extent to which any license | |||
| under such rights might or might not be available; nor does it | under such rights might or might not be available; nor does it | |||
| represent that it has made any independent effort to identify any | represent that it has made any independent effort to identify any | |||
| such rights. | such rights. | |||
| Copies of Intellectual Property disclosures made to the IETF | Copies of Intellectual Property disclosures made to the IETF | |||
| Secretariat and any assurances of licenses to be made available, or | Secretariat and any assurances of licenses to be made available, or | |||
| the result of an attempt made to obtain a general license or | the result of an attempt made to obtain a general license or | |||
| permission for the use of such proprietary rights by implementers or | permission for the use of such proprietary rights by implementers or | |||
| users of this specification can be obtained from the IETF on-line IPR | users of this specification can be obtained from the IETF on-line | |||
| repository at http://www.ietf.org/ipr | IPR repository at http://www.ietf.org/ipr | |||
| The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
| copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
| rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
| any standard or specification contained in an IETF Document. Please | any standard or specification contained in an IETF Document. Please | |||
| address the information to the IETF at ietf-ipr@ietf.org. | address the information to the IETF at ietf-ipr@ietf.org. | |||
| Disclaimer of Validity | Disclaimer of Validity | |||
| All IETF Documents and the information contained therein are provided | All IETF Documents and the information contained therein are | |||
| on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION | |||
| REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE | HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, | |||
| IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL | THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL | |||
| WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY | WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY | |||
| WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE | WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE | |||
| ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS | ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS | |||
| FOR A PARTICULAR PURPOSE. | FOR A PARTICULAR PURPOSE. | |||
| Acknowledgment | Acknowledgment | |||
| Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is currently provided by the | |||
| Internet Society. | Internet Society. | |||
| End of changes. 68 change blocks. | ||||
| 199 lines changed or deleted | 230 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||