Network Working Group Jianhua Gao Dan Li Internet Draft Huawei Category: Standards Track Expires: April 2007 October, 2006 Problem and Applicability Statement for the use of Generalized Multi-Protocol Label Switching (GMPLS) to Support Multiplex Section Shared Protection Ring (MS-SPRing) in Synchronous Digital Hierarchy (SDH) and Synchronous Optical Network (SONET) networks and Optical Transport Networks (OTNs) draft-gao-ccamp-gmpls-msspring-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract In order to provide high availability for transport networks, link protection technologies are adopted in the data plane. In present Synchronous Digital Hierarchy (SDH) and Synchronous Optical Network Li Expires April 2007 [Page 1] Internet-Draft draft-gao-ccamp-msspring-00.txt October 2006 (SONET)optical transport networks, shared ring protection technologies, such as the 2/4-Fiber Bi-directional Multiplex Section Shared Protection Ring(MS-SPRing), are widely used. The same technologies can also be applied in Optical Transport Networks (OTNs). This document describes a set of issues to be addressed when applying GMPLS) to support MS-SPRings, and sets out how GMPLS can be applied. Table of Contents 1. Introduction................................................2 2. Multiplex Section Shared Protection Ring Overview............3 2.1. 2-Fiber Bi-directional MS-SPRing........................3 2.2. 4-Fiber Bi-directional MS-SPRing........................3 2.3. Use of MS-SPRings within GMPLS Networks.................3 3. Issues with MS-SPRing........................................3 3.1. Advertising a TE Link that Crosses an MS-SPRing..........3 3.2. Re-Advertising the TE Link in Failure States............4 3.3. LSP Re-Routing After MS-SPRing Failure..................5 3.4. Consistent Resource/Label Usage.........................5 3.5. SRLG Consideration......................................5 4. Application of GMPLS to MS-SPRings...........................6 4.1. Routing................................................6 4.1.1. TE Link Advertisement..............................6 4.1.2. Re-Advertising TE Links............................6 4.1.3. SRLGs.............................................7 4.2. Signaling..............................................8 5. Security Considerations......................................8 6. Acknowledgments.............................................8 7. References..................................................9 7.1. Normative References....................................9 7.2. Informative References..................................9 8. Author's Addresses.........................................10 9. Full Copyright Statement....................................10 10. Intellectual Property Statement............................10 1. Introduction In order to provide high availability for transport networks, link protection technologies are adopted in the data plane. In present Synchronous Digital Hierarchy (SDH) and Synchronous Optical Network (SONET)optical transport networks, shared ring protection technologies, such as the 2/4-Fiber Bi-directional Multiplex Section Shared Protection Ring(MS-SPRing) [G.841], are widely used. The same technologies can also be applied in Optical Transport Networks (OTNs). This document describes a set of issues to be addressed when applying Li Expires April 2007 [Page 2] Internet-Draft draft-gao-ccamp-msspring-00.txt October 2006 Generalized Multiprotocol Label Switching (GMPLS) to support MS- SPRings, and sets out how GMPLS can be applied. 2. Multiplex Section Shared Protection Ring Overview I think that draft-caviglia has too much detail in the overview and explanation. MS-SPRing is well defined in other documents and it is not necessary to provide a full explanation here. It should be enough to give a few paragraphs describing the main features at a high level. That is, this is not a tutorial, it is a refresher and context. 2.1. 2-Fiber Bi-directional MS-SPRing Refer to: draft-caviglia-ccamp-gmpls-msspring-req-00.txt 2.2. 4-Fiber Bi-directional MS-SPRing Refer to: draft-caviglia-ccamp-gmpls-msspring-req-00.txt 2.3. Use of MS-SPRings within GMPLS Networks In this document, we only consider how to run GMPLS across an MS- SPRing. This document doesn't consider the following issues: - to control an MS-SPRing using GMPLS - to emulate an MS-SPRing using GMPLS - to share MS-SPRing resources between the ring and other services It is important to set this scope because the rest of the document depends on an understanding of what we are trying to use GMPLS for. 3. Issues with MS-SPRing 3.1. Advertising a TE Link that Crosses an MS-SPRing When an MS-SPRing exists within a GMPLS network it is able to support multiple TE links from ring entry points to ring exit points. Each TE link can use the features of the ring to provide protection for the traffic it carries. Li Expires April 2007 [Page 3] Internet-Draft draft-gao-ccamp-msspring-00.txt October 2006 For a 2-Fiber bi-directional MS-SPRing, there are two fibers for each span of the ring. Each fiber is equally divided into working and protection channels, that is, each fiber provides protection for traffic on the other fiber. Using the terminology of [RFC4202], the resources (i.e. timeslots or lambdas) on the data links that make up the ring have protection types "Shared" or "Extra Traffic". It is also desirable to support unprotected traffic across the data link whose part of resource has been configured with MS-SPring, so the resources may also have protection type "Unprotected". A 1:1 shared protection type TE link, for example, can be supported by two types link resources: one type of link resource is used to carry the protected traffic, another type of link resource is used to carry the extra traffic. The question arises of how to advertise the TE link between two nodes on the ring. Note that according to the definition in section 1.2 of [RFC4203], the GMPLS routing protocols only support one protection type per TE link. But should we advertise the shared, extra-traffic, or unprotected traffic capabilities of the link between the two nodes? For a 4-Fiber bi-directional MS-SPRing, there are two pairs of fibers for each span of the ring. Each pair of fibers is defined as working or protection channels. The same issue of choosing which protection capabilities to advertise exists for the 4-Fiber bi-directional MS- SPRing case. 3.2. Re-Advertising the TE Link in Failure States In 2/4-Fiber MS-SPRing, if a fiber is broken, all the protection TE links in MS-SPRing will be affected. For example, in 4-Fiber MS- SPRing, when a working fiber is broken, all the protected traffic is switched to the protection fiber. A link that previously offered "Enhanced" protection can now only provides the "Shared" protection for the protected traffic, and the link that was previously "Extra Traffic" can not carry the extra traffic any more. The link protection type would normally be configured and should not be affected by the link failure: either the link is available, or it isn't. But the available link resources change in the event of the link failure. The question is how to advertise (or re-advertise) the TE links in the case of a failure on the ring. Li Expires April 2007 [Page 4] Internet-Draft draft-gao-ccamp-msspring-00.txt October 2006 3.3. LSP Re-Routing After MS-SPRing Failure When a failure occurs in an MS-SPRing, the affected TE links will be re-advertised in the network in answer to the question in the previous section. LSPs that used the TE links across the ring may still be able to carry traffic (using the protection capabilities of the ring), or may have been displaced (because they were extra traffic, or because they were unprotected). The paths of the LSPs can be re-computed based on the current TE link capabilities, and the re-routing process may be invoked if necessary. The question to be answered here is which LSPs should be recomputed/re-routed first: those that have degraded protection (below the original service request level), but where the traffic is still being delivered; or those where the traffic has been completely disrupted? 3.4. Consistent Resource/Label Usage If there is a connection across the MS-SPRing through the two non- adjacent nodes then, according to the switching principle of MS- SPRing, when two link failures occur along the connection path in the MS-SPRing and there is still physical connectivity between the two non-adjacent nodes in the other direction around the MS-SPRing, the connection can be protected. Thus, if the label (time slot or wavelength) is changed at a transit node along the LSP's path around the MS-SPRing, it may not be possible to protect the LSP, and mis-connection may occur. The question arises of how to ensure that the LSP is allocated the same label (time slot or wavelength) along its path in the MS-SPRing to ensure that the LSP gains full maximal protection. 3.5. SRLG Consideration The nature of the MS-SPRing technology is that any failure in a ring may affect all of the TE links which cross the MS-SPRing. When computing paths across the network, it is desirable for the computation to be aware of TE links that appear to be disjoint but actually use the same underlying resources because these TE links are subject to the same failure conditions. This is usually achieved by defining a Shared Risk Link Group (SRLG) and having each TE link advertise its membership of the same group. Li Expires April 2007 [Page 5] Internet-Draft draft-gao-ccamp-msspring-00.txt October 2006 The question is how to indicate that two TE links that cross an MS- SPRing that may not have the same entry or exit point in common are members of the same SRLG, and how to coordinate the allocation of the SRLG ID for advertisement by the end points of the TE links. 4. Application of GMPLS to MS-SPRings 4.1. Routing 4.1.1. TE Link Advertisement When TE links are formed across an MS-SPRing the end points of the TE links (the entry and exit points from the ring) are responsible for advertising the TE links. There are two options: o Three distinct TE links may be advertised for each pair of adjacency nodes. Such advertisements would reflect the split of ring resources into working, protection/extra-traffic, and unprotected resources. That is, one TE link could be advertised as "1:1 Dedicated", one TE link as "Extra Traffic", and one TE link as "unprotected". An entity computing the path of an LSP through the network could then be aware of what resources existed at each capability, and could select the appropriate TE link for the level of service required. o A single TE link may be advertised with protection type "Enhanced". Path computation could select this link to support any protected traffic, extra traffic, or unprotected traffic. In this mode of operation, it is the responsibility of the entry node to allocate resources on the ring commensurate with service level requested for the LSP in the signaling message. A hybrid mechanism has been proposed where a single TE link could be advertised with multiple protection types. This is contrary to the specification in [RFC4202] and does not appear to gain anything over the second option stated above. Therefore, this document does not propose any extensions to the routing protocols. Should an operator wish to distinguish the different ring resources (or even ring directions) while still using the second option listed above, they can define a link bundle (see [RFC4201]). 4.1.2. Re-Advertising TE Links When resources are allocated from a TE link that crosses an MS-SPRing, this may affect the available resources on all other TE links that Li Expires April 2007 [Page 6] Internet-Draft draft-gao-ccamp-msspring-00.txt October 2006 cross the ring. This depends on the implementation of the MS-SPRing: if the resources are pre-allocated to each TE link (i.e. to each entry/exit node pair) then the only impact is to the TE links between the entry and exit points; but if the ring is operated as a dynamic entity, then using a resource in support of an LSP across one TE link may mean that the resource cannot be used by another TE link. Similarly, when a failure occurs in an MS-SPRing, the protection capabilities of some TE links may be decreased. Some TE links may become incapable of providing link level protection, and some may be completely broken. Lastly, when the ring is repaired, the protection capabilities of the TE links that cross the ring is restored. The new protection capabilities of a link can be advertised in a routing protocol update advertisement. As with advertisements for changes in available bandwidth, care should be taken by implementations not to generate updates too frequently. It may be better to favor updates that remove capabilities over updates that restore capabilities. Note that the coordination of the interaction between distinct TE links that cross the ring is the responsibility of the management system that control the MS-SPRing. 4.1.3. SRLGs [RFC4203] and [RFC4205] define how the SRLGs that apply to a TE link may be advertised by routing protocols. Management plane coordination can be used so that all nodes on an MS-SPRing know the SRLG ID for the ring and can advertise it as part of the TE link advertisements that they originate for TE links that cross the ring. It is possible that it will be advantageous for a path computing entity to know the type of association represented by an SRLG. For example, it may be beneficial to be able to distinguish an SRLG that means that two TE links share a duct, from and SRLG that means that two TE links cross the same road bridge. Similarly, it may be advantageous to know that the SRLG advertised indicates that the TE links share the same ring because this will indicate that the shared risk is graded through a loss of protection capabilities before a complete loss of connectivity. At the moment there are no classifications of SRLG IDs standardized. An operator is free to sub-divide the space of SRLG IDs within their Li Expires April 2007 [Page 7] Internet-Draft draft-gao-ccamp-msspring-00.txt October 2006 Administrative Domain and place meaning on the sub-divisions. Standardization of the classification of SRLGs is for future study. 4.2. Signaling If label continuity is the responsibility of the management plane then there is no additional requirement on GMPLS to control the allocation of labels within the ring, and the entry and exit nodes are responsible for selecting suitable labels for use on the TE link. In this case, if an inappropriate label is provided in the Explicit Route object (ERO) signaled to the entry point node, it may be necessary for the node to reject the signaling message. In order to support the consistent label allocation when the ring is controlled using GMPLS, the Label Set object can be used with a single label member for the LSPs signaled within the ring. If the label in label set object is not available on a certain node in the MS-SPRing, an Acceptable Label Set object can be returned to indicate which labels would have been consistently available. When failure occurs in a MSPRing, the data plane connection may be switched to a different protection path. The control plane will not reroute the affected end-to-end LSPs to align with the real data plane connection path because the LSPs are protected successfully, in perspective of LSPs that across the MS-SPRing, the control plane need not perceived failure in the TE link around MS-SPRing. 5. Security Considerations End-to-end security within the GMPLS network is not adversely impacted by the use of MS-SPRings within the network. Indeed, the protection properties of the ring enhance the resilience of the GMPLS LSP to physical attacks on the network infrastructure. The use of a GMPLS control plane to operate the MS-SPRing itself raises the same security benefits and concerns as exist when an entire network is migrated from the management plane (or from an pre- existing control plane) to GMPLS. Further notes on GMPLS security can be found in [RFC3945]. 6. Acknowledgments We would like to thank Adrian Farrel for his useful comments. Li Expires April 2007 [Page 8] Internet-Draft draft-gao-ccamp-msspring-00.txt October 2006 7. References 7.1. Normative References [RFC3945] Mannie, E., Ed., "Generalized Multiprotocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC4205] Kompella, K. Ed. and Y. Rekhter, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005. [G.841] ITU-T "Types and characteristics of SDH network protection architectures", October 1998. 7.2. Informative References [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. Li Expires April 2007 [Page 9] Internet-Draft draft-gao-ccamp-msspring-00.txt October 2006 8. Author's Addresses Jianhua Gao Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base, Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972902 Email: gjhhit@huawei.com Dan Li Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base, Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972910 Email: danli@huawei.com 9. Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 10. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Li Expires April 2007 [Page 10] Internet-Draft draft-gao-ccamp-msspring-00.txt October 2006 Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". Li Expires April 2007 [Page 11]