Network Working Group Young Lee Internet Draft Rajendra Damle Expiration Date: December 2001 Iris Labs Eric Brendel Coree Networks Riad Hartani Caspian Networks Vishal Sharma Metanoia June 2001 Protection Scheme for Optical Channel Concatenation draft-ylee-protection-occ-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are workingdocuments 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/1id-abstracts,html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This paper provides a framework for a protection scheme in the context of optical channel concatenation (OCC). The need and requirements for optical channel concatenation is addressed in a separate IETF draft, draft-damle-optical-channel-concatenation-00.txt,which has been submitted concurrently. This paper bascially provides mechanisms for faster failure detection and propagation of failure for concatenated optical channels. Standard-based MPLS protection schemes can be employed for the actual rerouting of traffic utilizing the detection and propagation mechanisms demonstrated in this paper. This contribution is presented herein for information only. 1. Introduction In todayÆs core POP, it is evident that backbone routers/switches directly interface to DWDM equipment bypassing SONET ADM equipment. This is an inevitable phenomenon due to the fact that router port speed Lee, et. al. [Page 1] Internet Draft draft-ylee-protection-occ-00.txt July 2001 has exceeded the SONET ADM port speed and, thus, the need for aggregation through ADM is not applicable at least for IP traffic. This results in unprotected IP traffic, which has been acceptable for best-effort applications. However, for the transport of emerging carrier-grade applications over IP networks, some level of robust protection mechanism is required. The point-to-point traffic demand exceeds the router/switch port speed as well as the optical transmission rate. Today, both the higher router port speed and the optical transmission rate are 10Gbps. The projected data growth for the next few years would require a much higher rate than the projected optical transmission rate of 40Gbps. Since the point-to-point traffic demand exceeds both the router port speed and underlying optical transmission rate, many backbone routers are clustered together to meet the demand. This ôclusteringö results in many parallel links in the core network posing serious management complexity. This issue will be aggravated unless both router ports and optical transmission rate are significantly augmented. Based on the above discussions, new requirements are placed on next-generation router design. These core routers need: - To subsume protection functions for carrier-grade applications - Higher speed ports with fewer numbers of total port counts - Port expansion that should not be limited by the underlying transmission rate To realize the third requirement mentioned above, an enabling technology that allows concatenation of optical transmission channels to occur at the port levels needs to exist. The resulting high-speed port can then accommodate exponential data growth above the optical transmission rate in a scalable manner. It is also ideal to incorporate protection schemes at this channel layer. This concatenated optical channel is referred to as a ôsuperchannelö in this paper. The need for optical channel concatenation has been addressed in recent T1X1.5 contributions [1]-[5]. 2. Superchannel Concept Figure 1 depicts todayÆs optical network architecture. Router/switch ports are connected over physical optical channel to DWDM terminal equipment. Typically, the optical channel and router/switch port speeds are 10Gbps in a core POP. Because of this bottleneck, when point-to- point traffic demand exceeds 10Gbps, multiple parallel links need to be maintained. Lee, et. al. [Page 2] Internet Draft draft-ylee-protection-occ-00.txt July 2001 Packet Switch/ WDM Transport System Packet Switch/ Router/OXC -----------^----------- Router/OXC ------------- / \ ------------- | |----- Mux -----| | | High speed | | |----|\ /|----| | | | | port --->| | |----| | | |----| | | | | | | |----| |---|\---------|\---| |----| | | | | | | |----| | |/ |/ | |----| | | | | |----- |/ Optical \| ^ -----| | | | ^ Amplifier | | | | | : | wavelength : | | | | : |_ Superchannel channel : | | | | Interface (subchannel) | | | |----- -----| | | | | |----|\ /|----| | | | | | | |----| | | |----| | | | | | | |----| |---|\---------|\---| |----| | | | | | | |----| | |/ |/ | |----| | | | | |----- |/ \| -----| | ------------- ------------- Figure 1: Reference Optical Network Architecture For example, to accommodate a 40Gbps point-to-point traffic demand between two core POPs, four 10Gbps channels are required. The protection of individual channels depends on the underlying framing protocol of the channel. Typically, packet over SONET (POS) interfaces are used for the router ports. Some router/switch implementations use the SONET overhead (K1 & K2 bytes) to detect channel failure and applies MPLS reroute capability to unload traffic from the failed channel. Other implementation strategies depend on layer 3 messages to detect link failure condition. An superchannel refers to a pipe in which many subchannels (wavelength channels) are concatenated together. This superchannel appears as one interface from the router/switch perspective, therefore, it is advertised as a single IGP link. To manage this pipe as one interface, a new framing structure is needed to bind together multiple channels. The implementation details concerning the framing methods are beyond the scope of this paper. Essential functional requirements of superchannel are found in [4]. 3. Integrated MPLS-Based Protection Mechanism This section discusses an integrated protection mechanism where an opticalchannel concatenation mechanism is integrated with MPLS capability. There are two levels of protection mechanism: - Subchannel level - Superchannel level Lee, et. al. [Page 3] Internet Draft draft-ylee-protection-occ-00.txt July 2001 3.1. Subchannel Protection Mechanism Figure 2 depicts a pair of routers/switches that are connected via a superchannel in which 4 wavelength channels are terminated in both of the superchannel interfaces A and B, respectively. Figure 2 also shows subchannel failure-detection mechanism using an OCC framing overhead. ----- ----- | |__________ ------------\--/-------->_________| | | S | sub ch 1 | \/ |sub ch 1| S | | U |__________|<------------/\----------|________| U | | P | / \ | P | | E | B(0,1,1,1) | E | | R |__________ ------------------------> ________| R | | | sub ch 2 | A(0,1,1,1) |sub ch 2| | | C |__________|<------------------------|________| C | | H | | H | | | | | | A | B(0,1,1,1) | B | | |__________ ------------------------> ________| | | | sub ch 3 | A(0,1,1,1) |sub ch 3| | | |__________|<------------------------|________| | | | | | | | B(0,1,1,1) | | | |__________ ------------------------> ________| | | | sub ch 4 | A(o,1,1,1) |sub ch 4| | | |__________|<------------------------|________| | | | | | ----- ----- Figure 2: Subchannel Protection Framing overhead can carry information associated with its superchannel and subchannels. For example, framing overhead bitmaps on each optical channel carry information concerning the status of all optical subchannels associated with the superchannel. This information can be transmitted with the payload or as OAM&P packets over each subchannel. When a subchannel fails, the receiving line interface associated with the failed subchannel will not receive the bitmap. This then triggers a new bitmap to be transmitted in the reverse direction, indicating a subchannel failure. On receipt of this status bitmap, the transmitting side stops sending data over this failed subchannel. Depending on the thresholding mechanism, subchannel failure event may not necessarily trigger re-routing of traffic. When there is still enough capacity in the superchannel after subchannel failure, traffic is distributed over the remaining subchannels bypassing the failed subchannels. This is referred to as subchannel resiliency. When subchannel failure results in hitting a pre-set threshold some or all of the Label Switched Paths (LSP) traversing the failed superchannel could be rerouted over the mated superchannel. This occurs based on the priority associated with the LSPs. The LSPs Lee, et. al. [Page 4] Internet Draft draft-ylee-protection-occ-00.txt July 2001 classified as protected should have back-up capacity on the alternative superchannel. This bandwidth reservation should occur at the provisioning time. 3.2. Superchannel Protection Mechanism Figure 3 depicts a pair of routers/switches that are connected via two disjoint superchannels. Each of the superchannel terminates four subchannels, respectively. ----- ----- | |__________ ------------\--/-------->_________| | | S | sub ch 1 | \/ |sub ch 1| S | | U |__________|<------------/\----------|________| U | | P | / \ | P | | E | | E | | R |__________ ------------\--/--------> ________| R | | | sub ch 2 | \/ |sub ch 2| | | C |__________|<------------/\----------|________| C | | H | / \ | H | -->| | | |<-- | | A | | B | | | | |__________ ------------\--/--------> ________| | | | | | sub ch 3 | \/ |sub ch 3| | | | | |__________|<------------/\----------|________| | | | | | / \ | | | | | | | | | | | |__________ ------------\--/--------> ________| | | | | | sub ch 4 | \/ |sub ch 4| | | | | |__________|<------------/\----------|________| | | | | | / \ | | | | ----- ----- | | | | ----- D(1,1,1,1);B(0,0,0,0) ----- | | | |__________ ------------------------>_________| | | | | S | sub ch 1 | C(1,1,1,1);A(0,0,0,0) |sub ch 1| S | | | | U |__________|<------------------------|________| U | | | | P | | P | | | | E | D(1,1,1,1);B(0,0,0,0) | E | | | | R |__________ ------------------------> ________| R | | | | | sub ch 2 | C(1,1,1,1);A(0,0,0,0) |sub ch 2| | | | | C |__________|<------------------------|________| C | | | | H | | H | | -->| | | |<-- | C | D(1,1,1,1);B(0,0,0,0) | D | | |__________ ------------------------> ________| | | | sub ch 3 | C(1,1,1,1);A(0,0,0,0) |sub ch 3| | | |__________|<------------------------|________| | | | | | | | D(1,1,1,1);B(0,0,0,0) | | | |__________ ------------------------> ________| | | | sub ch 4 | C(1,1,1,1);A(0,0,0,0) |sub ch 4| | | |__________|<------------------------|________| | | | | | ----- ----- Lee, et. al. [Page 5] Internet Draft draft-ylee-protection-occ-00.txt July 2001 Figure 3: Superchannel Protection FIgure 3 also shows superchannel protection mechanism. When all subchannels fail over superchannel A, there is no way to convey this failure condition in the reverse direction. This failure notification can occur using an alternative channels over the mated superchannel C. If any of the subchannels that belong to superchannel A fail, the status messages can still be sent to the upstream ports using any live subchannels on superchannel A. When the primary superchannel fails, the protected traffic is rerouted over the alternative superchannel. The unprotected traffic on the primary superchannel may not be protected while the protected traffic takes bandwidth on the alternative superchannel, thus bumping the pre-emptable traffic on the alternative superchannel. Compared to the SONET transport layer 1+1 protection where standby idle capacity needs to be reserved for protection, this supechannel protection allows these idle capacities to be used for best efforts application in normal network conditions, while providing the same protection level for the protected traffic in the failure condition. This is a significant improvement in bandwidth utilization. 5. References [1] T1X1.5/2000-157R1 "A Justification for a Variable Bandwidth Allocation Methodology for SONET Virtually Concatenated SPEs" [2] T1X1.5/2000-156 "A Proposal for Variable Bandwidth Allocation (VBA) Methodology for SONET Virtually Concatenated SPEs" [3] T1X1.5/2000-199 "A Proposed Link Capacity Adjustment Scheme (LCAS) for SONET Virtually Concatenated SPEs" [4] T1X1.5/2001-090 "Need for Concatenating Optical Channels to Create a Transparent High Bandwidth Channels" [5] T1X1.5/2001-103 "Clarification of T1X1.5/2001-090" 6. Security Considerations This draft does not introduce any new security considerations. 7. Authors' Addresses Young Lee Iris Labs Inc. 101 E. Park Blvd 855 Plano, TX 75025 Phone: 972 943 2964 Email: ylee@irislabs.com Lee, et. al. [Page 6] Internet Draft draft-ylee-protection-occ-00.txt July 2001 Rajendra Damle Iris Labs Inc. 101 E. Park Blvd 855 Plano, TX 75025 Phone: 972 943 2963 Email: rdamle@irislabs.com Eric Brendel Coree Networks 56 Park Road Tinton Falls, NJ 07724 Phone: 732 380 2800 Email: brendel@coreenetworks.com Riad Hartani Caspian Networks 170 Baytech Drive San Jose, CA 95143 Phone: 408 382 5216 Email: riad@caspiannetworks.com Vishal Sharma Metanoia, Inc. 335 Elan Village Lane Unit 203 San Jose, CA 95134-2539 Phone: 408-943-1794 Email: v.sharma@ieee.org Lee, et. al. [Page 7] Internet Draft draft-ylee-protection-occ-00.txt July 2001 Expiration Date: January 2002