summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2892.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2892.txt')
-rw-r--r--doc/rfc/rfc2892.txt2915
1 files changed, 2915 insertions, 0 deletions
diff --git a/doc/rfc/rfc2892.txt b/doc/rfc/rfc2892.txt
new file mode 100644
index 0000000..afa3a0c
--- /dev/null
+++ b/doc/rfc/rfc2892.txt
@@ -0,0 +1,2915 @@
+
+
+
+
+
+
+Network Working Group D. Tsiang
+Request for Comments: 2892 G. Suwala
+Category: Informational Cisco Systems
+ August 2000
+
+
+ The Cisco SRP MAC Layer Protocol
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ This document specifies the MAC layer protocol, "Spatial Reuse
+ Protocol" (SRP) for use with ring based media. This is a second
+ version of the protocol (V2).
+
+ The primary requirements for SRP are as follows:
+
+ - Efficient use of bandwidth using:
+ spatial reuse of bandwidth
+ local reuse of bandwidth
+ minimal protocol overhead
+ - Support for priority traffic
+ - Scalability across a large number of nodes or stations attached to
+ a ring
+ - "Plug and play" design without a software based station management
+ transfer (SMT) protocol or ring master negotiation as seen in
+ other ring based MAC protocols [1][2]
+ - Fairness among nodes using the ring
+ - Support for ring based redundancy (error detection, ring wrap,
+ etc.) similar to that found in SONET BLSR specifications.
+ - Independence of physical layer (layer 1) media type.
+
+ This document defines the terminology used with SRP, packet formats,
+ the protocol format, protocol operation and associated protocol
+ finite state machines.
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 1]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+Table of Contents
+
+ 1. Differences between SRP V1 and V2 ....................... 3
+ 2. Terms and Taxonomy ...................................... 4
+ 2.1. Ring Terminology .................................. 4
+ 2.2. Spatial Reuse ..................................... 5
+ 2.3. Fairness .......................................... 6
+ 2.4. Transit Buffer .................................... 7
+ 3. SRP Overview ............................................ 8
+ 3.1. Receive Operation Overview ........................ 8
+ 3.2. Transmit Operation Overview ....................... 8
+ 3.3. SRP Fairness Algorithm (SRP-fa) Overview .......... 9
+ 3.4. Intelligent Protection Switching (IPS) Protocol
+ Overview .......................................... 9
+ 4. Packet Formats .......................................... 13
+ 4.1. Overall Packet Format ............................. 13
+ 4.2. Generic Packet Header Format ...................... 14
+ 4.2.1. Time To Live (TTL) ......................... 14
+ 4.2.2. Ring Identifier (R) ........................ 15
+ 4.2.3. Priority Field (PRI) ....................... 15
+ 4.2.4. MODE ....................................... 15
+ 4.2.5. Parity Bit (P-bit) ......................... 16
+ 4.2.6. Destination Address ........................ 16
+ 4.2.7. Source Address ............................. 16
+ 4.2.8. Protocol Type .............................. 16
+ 4.3. SRP Cell Format ................................... 16
+ 4.4. SRP Usage Packet Format ........................... 17
+ 4.5. SRP Control Packet Format ......................... 18
+ 4.5.1. Control Ver ................................ 19
+ 4.5.2. Control Type ............................... 19
+ 4.5.3. Control TTL ................................ 19
+ 4.5.4. Control Checksum ........................... 19
+ 4.5.5. Payload .................................... 20
+ 4.5.6. Addressing ................................. 20
+ 4.6. Topology Discovery ................................ 20
+ 4.6.1. Topology Length ............................ 22
+ 4.6.2. Topology Originator ........................ 22
+ 4.6.3. MAC bindings ............................... 22
+ 4.6.4. MAC Type Format ............................ 22
+ 4.7. Intelligent Protection Switching (IPS) ............ 23
+ 4.7.1. Originator MAC Address ..................... 23
+ 4.7.2. IPS Octet .................................. 24
+ 4.8. Circulating packet detection (stripping) .......... 24
+ 5. Packet acceptance and stripping ......................... 25
+ 5.1. Transmission and forwarding with priority ......... 27
+ 5.2. Wrapping of Data .................................. 28
+ 6. SRP-fa Rules Of Operation ............................... 28
+ 6.1. SRP-fa pseudo-code ................................ 30
+
+
+
+Tsiang & Suwala Informational [Page 2]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ 6.2. Threshold settings ................................ 32
+ 7. SRP Synchronization ..................................... 32
+ 7.1. SRP Synchronization Examples ...................... 33
+ 8. IPS Protocol Description ................................ 34
+ 8.1. The IPS Request Types ............................. 35
+ 8.2. SRP IPS Protocol States ........................... 36
+ 8.2.1. Idle ....................................... 36
+ 8.2.2. Pass-through ............................... 36
+ 8.2.3. Wrapped .................................... 36
+ 8.3. IPS Protocol Rules ................................ 36
+ 8.3.1. SRP IPS Packet Transfer Mechanism .......... 36
+ 8.3.2. SRP IPS Signaling and Wrapping Mechanism ... 37
+ 8.4. SRP IPS Protocol Rules ............................ 38
+ 8.5. State Transitions ................................. 41
+ 8.6. Failure Examples .................................. 41
+ 8.6.1. Signal Failure - Single Fiber Cut Scenario . 41
+ 8.6.2. Signal Failure - Bidirectional Fiber Cut
+ Scenario ................................... 43
+ 8.6.3. Failed Node Scenario ....................... 45
+ 8.6.4. Bidirectional Fiber Cut and Node Addition
+ Scenarios .......................................... 47
+ 9. SRP over SONET/SDH ...................................... 48
+ 10. Pass-thru mode .......................................... 49
+ 11. References .............................................. 50
+ 12. Security Considerations ................................. 50
+ 13. IPR Notice .. ........................................... 50
+ 14. Acknowledgments ......................................... 50
+ 15. Authors' Addresses ...................................... 51
+ 16. Full Copyright Statement ................................ 52
+
+1. Differences between SRP V1 and V2
+
+ This document pertains to SRP V2. SRP V1 was a previously published
+ draft specification. The following lists V2 feature differences from
+ V1:
+
+ - Reduction of the header format from 4 bytes to 2 bytes.
+
+ - Replacement of the keepalive packet with a new control packet that
+ carries usage information in addition to providing a keepalive
+ function.
+
+ - Change bit value of inner ring to be 1 and outer to be 0.
+
+ - Reduction in the number of TTL bits from 11 to 8.
+
+ - Removal of the DS bit.
+
+
+
+
+Tsiang & Suwala Informational [Page 3]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ - Change ordering of CRC transmission to be most significant octet
+ first (was least significant octet in V1). The SRP CRC is now the
+ same as in [5].
+
+ - Addition of the SRP cell mode to carry ATM cells over SRP.
+
+ - Changes to the SRP-fa to increase the usage field width and to
+ remove the necessity of adding a fixed constant when propagating
+ usage messages.
+
+2. Terms and Taxonomy
+
+2.1. Ring Terminology
+
+ SRP uses a bidirectional ring. This can be seen as two symmetric
+ counter-rotating rings. Most of the protocol finite state machines
+ (FSMs) are duplicated for the two rings.
+
+ The bidirectional ring allows for ring-wrapping in case of media or
+ station failure, as in FDDI [1] or SONET/SDH [3]. The wrapping is
+ controlled by the Intelligent Protection Switching (IPS) protocol.
+
+ To distinguish between the two rings, one is referred to as the
+ "inner" ring, the other the "outer" ring. The SRP protocol operates
+ by sending data traffic in one direction (known as "downstream") and
+ it's corresponding control information in the opposite direction
+ (known as "upstream") on the opposite ring. Figure 1 highlights this
+ graphically.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 4]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ FIGURE 1. Ring Terminology
+
+ {outer_data
+ ----- inner_ctl}
+ ---------------->| N |-----------------
+ | ---------------| 1 |<-------------- |
+ | | {inner_data ----- | |
+ | | outer_ctl} | |
+ ----- -----
+ | N | | N |
+ | 6 | | 2 |
+ ----- -----
+ ^ | ^ |
+ o | | i | |
+ u | | n | |
+ t | | n | |
+ e | | e | |
+ r | | r | |
+ | v | v
+ ----- -----
+ | N | | N |
+ | 5 | | 3 |
+ ----- -----
+ | | | |
+ | | ----- | |
+ | -------------->| N |--------------- |
+ -----------------| 4 |<----------------
+ -----
+
+2.2. Spatial Reuse
+
+ Spatial Reuse is a concept used in rings to increase the overall
+ aggregate bandwidth of the ring. This is possible because unicast
+ traffic is only passed along ring spans between source and
+ destination nodes rather than the whole ring as in earlier ring based
+ protocols such as token ring and FDDI.
+
+ Figure 2 below outlines how spatial reuse works. In this example,
+ node 1 is sending traffic to node 4, node 2 to node 3 and node 5 to
+ node 6. Having the destination node strip unicast data from the ring
+ allows other nodes on the ring who are downstream to have full access
+ to the ring bandwidth. In the example given this means node 5 has
+ full bandwidth access to node 6 while other traffic is being
+ simultaneously transmitted on other parts of the ring.
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 5]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+2.3. Fairness
+
+ Since the ring is a shared media, some sort of access control is
+ necessary to ensure fairness and to bound latency. Access control can
+ be broken into two types which can operate in tandem:
+
+ Global access control - controls access so that everyone gets a
+ fair share of the global bandwidth of the ring.
+
+ Local access control - grants additional access beyond that
+ allocated globally to take advantage of segments of the ring that
+ are less than fully utilized.
+
+ As an example of a case where both global and local access are
+ required, refer again to Figure 2. Nodes 1, 2, and 5 will get 1/2 of
+ the bandwidth on a global allocation basis. But from a local
+ perspective, node 5 should be able to get all of the bandwidth since
+ its bandwidth does not interfere with the fair shares of nodes 1 and
+ 2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 6]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ FIGURE 2. Global and Local Re-Use
+
+ . . . . . . . . . . . . . . . . .
+ . .
+ ----- .
+ ---------------->| N |----------------- .
+ | ---------------| 1 |<-------------- | .
+ | | ----- | | .
+ | | | | .
+ ----- ----- .
+ . .>| N | | N |. .. .
+ . | 6 | | 2 | . .
+ . ----- ----- . .
+ . ^ | ^ | . .
+ . o | | i | | . .
+ . u | | n | | . .
+ . t | | n | | . .
+ . e | | e | | . .
+ . r | | r | | . .
+ . | v | v . .
+ . ----- ----- . .
+ . . | N | | N |<. . .
+ | 5 | | 3 | .
+ ----- ----- .
+ | | | | .
+ | | ----- | | .
+ | -------------->| N |--------------- | .
+ -----------------| 4 |<---------------- .
+ ----- .
+ ^ .
+ . .
+ . . . . .<. . . . . . . . . . . .
+
+2.4. Transit Buffer
+
+ To be able to detect when to transmit and receive packets from the
+ ring, SRP makes use of a transit (sometimes referred as insertion)
+ buffer as shown in Figure 3 below. High priority packets and low
+ priority packets can be placed into separate fifo queues.
+
+
+
+
+
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 7]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ FIGURE 3. Transit buffer
+
+ ^^ ||
+ || vv
+ |----| |----|
+ | | | |
+ |----|Rx |----|Tx
+ | |Buffer | |Buffer
+ |----| |----|
+ | | | |
+ |----| |----|
+ | | | |
+ |----| |----|
+ | | | |
+ |----| |----|
+ ^^ Transit ||
+ || Buffer ||
+ || |------| vv
+ | H |
+ ===========>|------|==========>
+ | L |
+ |------|
+
+3. SRP Overview
+
+3.1. Receive Operation Overview
+
+ Receive Packets entering a node are copied to the receive buffer if a
+ Destination Address (DA) match is made. If a DA matched packet is
+ also a unicast, then the packet will be stripped. If a packet does
+ not DA match or is a multicast and the packet does not Source Address
+ (SA) match, then the packet is placed into the Transit Buffer (TB)
+ for forwarding to the next node if the packet passes Time To Live and
+ Cyclic Redundancy Check (CRC) tests.
+
+3.2. Transmit Operation Overview
+
+ Data sent from the node is either forwarded data from the TB or
+ transmit data originating from the node via the Tx Buffer. High
+ priority forwarded data always gets sent first. High priority
+ transmit data may be sent as long as the Low Priority Transit Buffer
+ (LPTB) is not full.
+
+ A set of usage counters monitor the rate at which low priority
+ transmit data and forwarded data are sent. Low priority data may be
+ sent as long as the usage counter does not exceed an allowed usage
+ governed by the SRP-fa rules and the LPTB has not exceeded the low
+ priority threshold.
+
+
+
+Tsiang & Suwala Informational [Page 8]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+3.3. SRP Fairness Algorithm (SRP-fa) Overview
+
+ If a node experiences congestion, then it will advertise to upstream
+ nodes via the opposite ring the value of its transmit usage counter.
+ The usage counter is run through a low pass filter function to
+ stabilize the feedback. Upstream nodes will adjust their transmit
+ rates so as not to exceed the advertised values. Nodes also
+ propagate the advertised value received to their immediate upstream
+ neighbor. Nodes receiving advertised values who are also congested
+ propagate the minimum of their transmit usage and the advertised
+ usage.
+
+ Congestion is detected when the depth of the low priority transit
+ buffer reaches a congestion threshold.
+
+ Usage messages are generated periodically and also act as keepalives
+ informing the upstream station that a valid data link exists.
+
+3.4. Intelligent Protection Switching (IPS) Protocol Overview
+
+ An SRP Ring is composed of two counter-rotating, single fiber rings.
+ If an equipment or fiber facility failure is detected, traffic going
+ towards and from the failure direction is wrapped (looped) back to go
+ in the opposite direction on the other ring (subject to the
+ protection hierarchy). The wrap around takes place on the nodes
+ adjacent to the failure, under control of the IPS protocol. The wrap
+ re-routes the traffic away from the failed span.
+
+ An example of the data paths taken before and after a wrap are shown
+ in Figures 4 and 5. Before the fiber cut, N4 sends to N1 via the
+ path N4->N5->N6->N1.
+
+ If there is a fiber cut between N5 and N6, N5 and N6 will wrap the
+ inner ring to the outer ring. After the wraps have been set up,
+ traffic from N4 to N1 initially goes through the non-optimal path
+ N4->N5->N4->N3->N2->N1->N6->N1.
+
+ Subsequently a new ring topology is discovered and a new optimal path
+ is used N4->N3->N2-N1 as shown in Figure 6. Note that the topology
+ discovery and the subsequent optimal path selection are not part of
+ the IPS protocol.
+
+
+
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 9]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ FIGURE 4. Data path before wrap, N4 -> N1
+
+ -----
+ ################>| N |-----------------
+ # ---------------| 1 |<-------------- |
+ # | ----- | |
+ # | | |
+ ----- -----
+ | N | | N |
+ | 6 | | 2 |
+ ----- -----
+ ^ | ^ |
+ # | | |
+ # | | |
+ # | | |
+ # | | |
+ # | | |
+ # v | v
+ ----- -----
+ | N | | N |
+ | 5 | | 3 |
+ ----- -----
+ # | | |
+ # | ----- | |
+ # -------------->| N |--------------- |
+ #################| 4 |<----------------
+ -----
+
+ The ring wrap is controlled through SONET BLSR [3][4] style IPS
+ signaling. It is an objective to perform the wrapping as fast as in
+ the SONET equipment or faster.
+
+ The IPS protocol processes the following request types (in the order
+ of priority, from highest to lowest):
+
+ 1. Forced Switch (FS): operator originated, performs a protection
+ switch on a requested span (wraps at both ends of the span)
+
+ 2. Signal Fail (SF): automatic, caused by a media Signal Failure
+ or SRP keep-alive failure - performs a protection switch on a
+ requested span
+
+
+
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 10]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ FIGURE 5. Data path after the wrap, N4 -> N1
+
+ -----
+ ################>| N |-----------------
+ # ###############| 1 |<############## |
+ # # ----- # |
+ # v # |
+ ----- -----
+ | N | | N |
+ | 6 | | 2 |
+ ----- -----
+ ^ # wrap ^ |
+ ### # |
+ _________ # |
+ fiber cut # |
+ --------- # |
+ ### # |
+ # v wrap # v
+ ----- -----
+ | N | | N |
+ | 5 | | 3 |
+ ----- -----
+ # # # |
+ # # ----- # |
+ # ##############>| N |############### |
+ #################| 4 |<----------------
+
+
+ 3. Signal Degrade (SD): automatic, caused by a media Signal
+ Degrade (e.g. excessive Bit Error Rate) - performs a protection
+ switch on a requested span
+
+ 4. Manual Switch (MS): operator originated, like Forced Switched
+ but of a lower priority
+
+ 5. Wait to Restore (WTR): automatic, entered after the working
+ channel meets the restoration criteria after SF or SD condition
+ disappears. IPS waits WTR period before restoring traffic in
+ order to prevent protection switch oscillations
+
+ If a protection (either automatic or operator originated) is
+ requested for a given span, the node on which the protection has been
+ requested issues a protection request to the node on the other end of
+ the span using both the short path (over the failed span, as the
+ failure may be unidirectional) and the long path (around the ring).
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 11]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ FIGURE 6. Data path after the new topology is discovered
+
+ -----
+ -----------------| N |-----------------
+ | ---------------| 1 |<############## |
+ | | ----- # |
+ | v # |
+ ----- -----
+ | N | | N |
+ | 6 | | 2 |
+ ----- -----
+ ^ | wrap ^ |
+ -- # |
+ _________ # |
+ fiber cut # |
+ --------- # |
+ -- # |
+ | v wrap # v
+ ----- -----
+ | N | | N |
+ | 5 | | 3 |
+ ----- -----
+ | | # |
+ | | ----- # |
+ | -------------->| N |############### |
+ -----------------| 4 |<----------------
+ -----
+
+ As the protection requests travel around the ring, the protection
+ hierarchy is applied. If the requested protection switch is of the
+ highest priority e.g. Signal Fail request is of higher priority than
+ the Signal Degrade than this protection switch takes place and the
+ lower priority switches elsewhere in the ring are taken down, as
+ appropriate. If a lower priority request is requested, it is not
+ allowed if a higher priority request is present in the ring. The only
+ exception is multiple SF and FS switches, which can coexist in the
+ ring.
+
+ All protection switches are performed bidirectionally (wraps at both
+ ends of a span for both transmit and receive directions, even if a
+ failure is only unidirectional).
+
+
+
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 12]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+4. Packet Formats
+
+ This section describes the packet formats used by SRP. Packets can be
+ sent over any point to point link layer (e.g. SONET/SDH, ATM, point
+ to point ETHERNET connections). The maximum transfer unit (MTU) is
+ 9216 octets. The minimum transfer unit for data packets is 55
+ octets. The maximum limit was designed to accommodate the large IP
+ MTUs of IP over AAL5. SRP also supports ATM cells. ATM cells over
+ SRP are 55 octets. The minimum limit corresponds to ATM cells
+ transported over SRP. The minimum limit does not apply to control
+ packets which may be smaller.
+
+ These limits include everything listed in Figure 7: but are exclusive
+ of the frame delineation (e.g. for SRP over SONET/SDH, the flags used
+ for frame delineation are not included in the size limits).
+
+ The following packet and cell formats do not include any layer 1
+ frame delineation. For SRP over POS, there will be an additional
+ flag that delineates start and end of frame.
+
+4.1. Overall Packet Format
+
+ The overall packet format is show below in Figure 7:
+
+ FIGURE 7. Overall Packet Format
+
+ ---------------------------------
+ | SRP Header |
+ ---------------------------------
+ | Dest. Addr. |
+ ---------------------------------
+ | Source Addr. |
+ ---------------------------------
+ | Protocol Type |
+ ---------------------------------
+ | Payload |
+ | |
+ | |
+ | |
+ ---------------------------------
+ | FCS |
+ ---------------------------------
+
+ The frame check sequence (FCS) is a 32-bit cyclic redundancy check
+ (CRC) as specified in RFC-1662 and is the same CRC as used in Packet
+ Over SONET (POS - specified in RFC-2615). The generator polynomial
+ is:
+
+
+
+
+Tsiang & Suwala Informational [Page 13]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ CRC-32:
+
+ x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 +
+ x2 + x + 1
+
+ The FCS is computed over the destination address, source address,
+ protocol type and payload. It does not include the SRP header.
+
+ Note that the packet format after the SRP header is identical to
+ Ethernet Version 2.
+
+4.2. Generic Packet Header Format
+
+ Each packet has a fixed-sized header. The packet header format is
+ shown in Figure 8.
+
+ FIGURE 8. Detailed Packet Header Format
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Time to Live |R| MOD | PRI |P| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination Address |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Source Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | Protocol Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | Payload |
+ . .
+ . .
+ . .
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The fields are described below.
+
+4.2.1. Time To Live (TTL)
+
+ This 8 bit field is a hop-count that must be decremented every time a
+ node forwards a packet. If the TTL reaches zero it is stripped off
+ the ring. This allows for a total node space of 256 nodes on a ring.
+ However, due to certain failure conditions (e.g. when the ring is
+
+
+
+
+
+Tsiang & Suwala Informational [Page 14]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ wrapped) the total number of nodes that are supported by SRP is 128.
+ When a packet is first sent onto the ring the TTL should be set to at
+ least twice the total number of nodes on the ring.
+
+4.2.2. Ring Identifier (R)
+
+ This single bit field is used to identify which ring this packet is
+ designated for. The designation is as follows:
+
+ TABLE 1. Ring Indicator Values
+
+ Outer Ring 0
+ Inner Ring 1
+
+4.2.3. Priority Field (PRI)
+
+ This three bit field indicates the priority level of the SRP packet
+ (0 through 7). The higher the value the higher the priority. Since
+ there are only two queues in the transit buffer (HPTB and LPTB) a
+ packet is treated as either low or high priority once it is on the
+ ring. Each node determines the threshold value for determining what
+ is considered a high priority packet and what is considered a low
+ priority packet. However, the full 8 levels of priority in the SRP
+ header can be used prior to transmission onto the ring (transmit
+ queues) as well as after reception from the ring (receive queues).
+
+4.2.4. MODE
+
+ This three bit field is used to identify the mode of the packet. The
+ following modes are defined in Table 2 below.
+
+ TABLE 2. MODE Values
+
+ Value Description
+
+ 000 Reserved
+ 001 Reserved
+ 010 Reserved
+ 011 ATM cell
+ 100 Control Message (Pass to host)
+ 101 Control Message (Locally Buffered for host)
+ 110 Usage Message
+ 111 Packet Data
+
+ These modes will be further explained in later sections.
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 15]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+4.2.5. Parity Bit (P-bit)
+
+ The parity bit is used to indicate the parity value over the 15 bits
+ of the SRP header to provide additional data integrity over the
+ header. Odd parity is used (i.e. the number of ones including the
+ parity bit shall be an odd number).
+
+4.2.6. Destination Address
+
+ The destination address is a globally unique 48 bit address assigned
+ by the IEEE.
+
+4.2.7. Source Address
+
+ The source address is a globally unique 48 bit address assigned by
+ the IEEE.
+
+4.2.8. Protocol Type
+
+ The protocol type is a two octet field like that used in EtherType
+ representation. Current defined values relevant to SRP are defined in
+ Table 3 below.
+
+ TABLE 3. Defined Protocol Types
+
+ Value Protocol Type
+
+ 0x2007 SRP Control
+ 0x0800 IP version 4
+ 0x0806 ARP
+
+4.3. SRP Cell Format
+
+ SRP also supports the sending of ATM cells. The detailed cell format
+ is shown below:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 16]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ FIGURE 9. SRP Cell Format
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Time to Live |R| MOD | PRI |P| VPI/VCI |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | VCI | PTI |C| HEC | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+ | |
+ . .
+ . ATM Payload .
+ . ( 48 Bytes ) +-+-+-+-+-+-+-+-+
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Packet nodes would typically ignore (never receive or strip) and
+ always forward ATM-cells. The idea is that ATM switches and routers
+ could coexist in a ring. Note that SRP cells do not contain an FCS.
+ Data integrity is handled at the AAL layer.
+
+4.4. SRP Usage Packet Format
+
+ SRP usage packets are sent out periodically to propagate allowed
+ usage information to upstream nodes. SRP usage packets also perform
+ a keepalive function. SRP usage packets should be sent approximately
+ every 106 usec.
+
+ If a receive interface has not seen a usage packet within the
+ keepalive timeout interval it will trigger an L2 keepalive timeout
+ interrupt/event. The IPS software will subsequently mark that
+ interface as faulty and initiate a protection switch around that
+ interface. The keepalive timeout interval should be set to 16 times
+ the SRP usage packet transmission interval.
+
+ FIGURE 10. Usage Packet Format
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Time to Live |R| MOD | PRI |P| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Originator MAC Address +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved | Usage |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ A USAGE of all ones indicates a value of NULL.
+
+
+
+Tsiang & Suwala Informational [Page 17]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+4.5. SRP Control Packet Format
+
+ If the MODE bits are set to 10X (SRP control) then this indicates a
+ control message. Control messages are always received and stripped by
+ the adjacent node. They are by definition unicast, and do not need
+ any addressing information. The destination address field for
+ control packets should be set to 0's. The source address field for a
+ control packet should be set to the source address of the
+ transmitting node.
+
+ Two types of controls messages are defined : Pass to host and Locally
+ buffered. Pass to host messages can be passed to the host software by
+ whatever means is convenient. This is most often the same path used
+ to transfer data packets to the host. Locally buffered control
+ messages are usually reserved for protection messages. These are
+ normally buffered locally in order to not contend for resources with
+ data packets. The actual method of handling these messages is up to
+ the implementor.
+
+ The control packet format is shown in Figure 11.
+
+ FIGURE 11. Control Packet Format
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Time to Live |R| MOD | PRI |P| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination Address |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Source Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | Protocol Type = 0x2007 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Ver | Control Type | Control Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control TTL | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+ . .
+ . Payload .
+ . .
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The priority (PRI) value should be set to 0x7 (all one's) when
+ sending control packets and should be queued to the highest priority
+ transmit queue available. The Time to Live is not relevant since all
+
+
+
+
+
+Tsiang & Suwala Informational [Page 18]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ packets will be received and stripped by the nearest downstream
+ neighbor and can be set to any value (preferably this should be set
+ to 001).
+
+4.5.1. Control Ver
+
+ This one octet field is the version number associated with the
+ control type field. Initially, all control types will be version 0.
+
+4.5.2. Control Type
+
+ This one octet field represents the control message type. Table 4
+ contains the currently defined control types.
+
+ TABLE 4. Control Types
+
+ Control Type Description
+
+ 0x01 Topology Discovery
+
+ 0x02 IPS message
+
+ 0x03-
+ 0xFF Reserved
+
+4.5.3. Control TTL
+
+ The Control TTL is a control layer hop-count that must be decremented
+ every time a node forwards a control packet. If a node receives a
+ control packet with a control TTL <= 1, then it should accept the
+ packet but not forward it.
+
+ Note that the control layer hop count is separate from the SRP L2 TTL
+ which is always set to 1 for control messages.
+
+ The originator of the control message should set the initial value of
+ the control TTL to the SRP L2 TTL normally used for data packets.
+
+4.5.4. Control Checksum
+
+ The checksum field is the 16 bit one's complement of the one's
+ complement sum of all 16 bit words starting with the control version.
+ If there are an odd number of octets to be checksummed, the last
+ octet is padded on the right with zeros to form a 16 bit word for
+ checksum purposes. The pad is not transmitted as part of the
+ segment. While computing the checksum, the checksum field itself is
+ replaced with zeros. This is the same checksum algorithm as that
+ used for TCP. The checksum does not cover the 32 bit SRP FCS.
+
+
+
+Tsiang & Suwala Informational [Page 19]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+4.5.5. Payload
+
+ The payload is a variable length field dependent on the control type.
+
+4.5.6. Addressing
+
+ All nodes must have a globally unique IEEE 48 bit MAC address. A
+ multicast bit is defined using canonical addressing conventions i.e.
+ the multicast bit is the least significant bit of the most
+ significant octet in the destination address. It is acceptable but
+ not advisable to change a node's MAC address to one that is known to
+ be unique within the administrative layer 2 domain (that is the SRP
+ ring itself along with any networks connected to the SRP ring via a
+ layer 2 transparent bridge).
+
+ FIGURE 12. Multicast bit position
+
+ Destination Address
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |M| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ^
+ |----Multicast bit
+
+ Note that for SONET media, the network order is MSB of each octet
+ first, so that as viewed on the line, the multicast bit will be the
+ 8th bit of the destination address sent. (For SRP on Ethernet media,
+ the multicast bit would be sent first).
+
+4.6. Topology Discovery
+
+ Each node performs topology discovery by sending out topology
+ discovery packets on one or both rings. The node originating a
+ topology packet marks the packet with the egressing ring id, appends
+ the node's mac binding to the packet and sets the length field in the
+ packet before sending out the packet. This packet is a point-to-point
+ packet which hops around the ring from node to node. Each node
+ appends its mac address binding, updates the length field and sends
+ it to the next hop on the ring. If there is a wrap on the ring, the
+ wrapped node will indicate a wrap when appending its mac binding and
+ wrap the packet. When the topology packets travel on the wrapped
+ section with the ring identifier being different from that of the
+ topology packet itself, the mac address bindings are not added to the
+ packet.
+
+
+
+
+
+Tsiang & Suwala Informational [Page 20]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ Eventually the node that generated the topology discovery packet gets
+ back the packet. The node makes sure that the packet has the same
+ ingress and egress ring id before excepting the packet. A topology
+ map is changed only after receiving two topology packets which
+ indicate the same new topology (to prevent topology changes on
+ transient conditions).
+
+ Note that the topology map only contains the reachable nodes. It does
+ not correspond to the failure-free ring in case of wraps and ring
+ segmentations.
+
+ FIGURE 13. Topology Packet Format
+
+ Topology
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Time to Live |R| MOD | PRI |P| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination Address |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Source Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | Protocol Type = 0x2007 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Ver=0 | Control Type=1| Control Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control TTL | Topology Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Originator's Globally Unique |
+ + MAC Address (48 bits) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | MAC Type | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+ | MAC Address (48 bits) |
+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | Other MAC bindings |
+ +-+-+-+-+-+-+-+-+ +
+ | |
+ + +
+
+ Note that the Source address should be set to the source address of
+ the TRANSMITTING node (which is not necessarily the ORIGINATING
+ node).
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 21]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+4.6.1. Topology Length
+
+ This two octet field represents the length of the topology message in
+ octets starting with the first MAC Type/MAC Address binding.
+
+4.6.2. Topology Originator
+
+ A topology discovery packet is determined to have been originated by
+ a node if the originator's globally unique MAC address of the packet
+ is that node's globally unique MAC address (assigned by the IEEE).
+
+ Because the mac addresses could be changed at a node, the IEEE MAC
+ address ensures that a unique identifier is used to determine that
+ the topology packet has gone around the ring and is to be consumed.
+
+4.6.3. MAC bindings
+
+ Each MAC binding shall consist of a MAC Type field followed by the
+ node's 48 bit MAC address. The first MAC binding shall be the MAC
+ binding of the originator. Usually the originator's MAC address will
+ be it's globally unique MAC Address but some implementations may
+ allow this value to be overridden by the network administrator.
+
+4.6.4. MAC Type Format
+
+ This 8 bit field is encoded as follows:
+
+ TABLE 5. MAC Type Format
+
+ Bit Value
+
+ 0 Reserved
+ 1 Ring ID (1 or 0)
+ 2 Wrapped Node (1) / Unwrapped Node (0)
+ 3-7 Reserved
+
+ Determination of whether a packet's egress and ingress ring ID's are
+ a match should be done by using the Ring ID found in the MAC Type
+ field of the last MAC binding as the ingress ring ID rather than the
+ R bit found in the SRP header. Although they should be the same, it
+ is better to separate the two functions as some implementations may
+ not provide the SRP header to upper layer protocols.
+
+ The topology information is not required for the IPS protection
+ mechanism. This information can be used to calculate the number of
+ nodes in the ring as well as to calculate hop distances to nodes to
+ determine the shortest path to a node (since there are two counter-
+ rotating rings).
+
+
+
+Tsiang & Suwala Informational [Page 22]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ The implementation of the topology discovery mechanism could be a
+ periodic activity or on "a need to discover" basis. In the periodic
+ implementation, each node generates the topology packet periodically
+ and uses the cached topology map until it gets a new one. In the need
+ to discover implementation, each node generates a topology discovery
+ packet whenever they need one e.g., on first entering a ring or
+ detecting a wrap.
+
+4.7. Intelligent Protection Switching (IPS)
+
+ IPS is a method for automatically recovering from various ring
+ failures and line degradation scenarios. The IPS packet format is
+ outlined in Figure 14 below.
+
+ FIGURE 14. IPS Packet Format
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Time to Live |R| MOD | PRI |P| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination Address |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Source Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | Protocol Type = 0x2007 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Ver=0 | Control Type=2| Control Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control TTL | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+ | Originator MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ips Octet | Rsvd Octet |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The IPS specific fields are detailed below.
+
+4.7.1. Originator MAC Address
+
+ This is the MAC address of the originator of the IPS message. It is
+ not necessarily the same as the SRP Header Source Address as a node
+ may be simply propagating an IPS message (see the section "SRP IPS
+ Protocol Rules" Rule P.8 as an example).
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 23]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+4.7.2. IPS Octet
+
+ The IPS octet contains specific protection information. The format of
+ the IPS octet is as follows:
+
+ FIGURE 15. IPS Octet Format:
+
+ Bits Values (values not listed are reserved)
+
+ 0-3 IPS Request Type
+
+ 1101 - Forced Switch (FS)
+ 1011 - Signal Fail (SF)
+ 1000 - Signal Degrade (SD)
+ 0110 - Manual Switch (MS)
+ 0101 - Wait to Restore (WTR)
+ 0000 - No Request (IDLE)
+
+ 4 Path indicator
+
+ 0 - short (S)
+ 1 - long (L)
+
+ 5-7 Status Code
+
+ 010 - Protection Switch Completed - traffic Wrapped (W)
+ 000 - Idle (I)
+
+ The currently defined request types with values, hierarchy and
+ interpretation are as used in SONET BLSR [3], [4], except as noted.
+
+4.8. Circulating packet detection (stripping)
+
+ Packets continue to circulate when transmitted packets fail to get
+ stripped. Unicast packets are normally stripped by the destination
+ station or by the source station if the destination station has
+ failed. Multicast packets are only stripped by the source station. If
+ both the source and destination stations drop out of the ring while a
+ unicast packet is in flight, or if the source node drops out while
+ its multicast packet is in flight, the packet will rotate around the
+ ring continuously.
+
+ The solution to this problem is to have a TTL or Time To Live field
+ in each packet that is set to at least twice the number of nodes in
+ the ring. As each node forwards the packet, it decrements the TTL. If
+ the TTL reaches zero it is stripped off of the ring.
+
+
+
+
+
+Tsiang & Suwala Informational [Page 24]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ The ring ID is used to qualify all stripping and receive decisions.
+ This is necessary to handle the case where packets are being wrapped
+ by some node in the ring. The sending node may see its packet on the
+ reverse ring prior to reaching its destination so must not source
+ strip it. The exception is if a node is in wrap. Logically, a node
+ in wrap "sees" the packet on both rings. However the usual
+ implementation is to receive the packet on one ring and to transmit
+ it on the other ring. Therefore, a node that is in the wrap state
+ ignores the ring ID when making stripping and receiving decisions.
+
+ A potential optimization would be to allow ring ID independent
+ destination stripping of unicast packets. One problem with this is
+ that packets may be delivered out of order during a transition to a
+ wrap condition. For this reason, the ring ID should always be used as
+ a qualifier for all strip and receive decisions.
+
+5. Packet acceptance and stripping
+
+ A series of decisions based on the type of packet (mode), source and
+ destination addresses are made on the MAC incoming packets. Packets
+ can either be control or data packets. Control packets are stripped
+ once the information is extracted. The source and destination
+ addresses are checked in the case of data packets. The rules for
+ reception and stripping are given below as well as in the flow chart
+ in Figure 16.
+
+ 1. Decrement TTL on receipt of a packet, discard if it gets to
+ zero; do not forward.
+
+ 2. Strip unicast packets at the destination station. Accept and
+ strip "control" packets.
+
+ 3. Do not process packets other than for TTL and forwarding if
+ they have the "wrong" ring_id for the direction in which they
+ are received unless the node is in wrap. If the node is in
+ wrap then ignore the ring_id.
+
+ 4. Do not process packets other than for TTL and forwarding if the
+ mode is not supported by the node (e.g. reserved modes, or ATM
+ cell mode for packet nodes).
+
+ 5. Packets accepted by the host because of the destination address
+ should be discarded at the upper level if there is CRC error.
+
+ 6. Control messages are point to point between neighbors and
+ should always be accepted and stripped.
+
+
+
+
+
+Tsiang & Suwala Informational [Page 25]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ 7. Packets whose source address is that of the receiving station
+ and whose ring_id matches should be stripped. If a node is in
+ wrap then ignore the ring_id.
+
+ FIGURE 16. SRP Receive Flowchart (Packet node)
+
+ if (MODE == 4,5)-------------------------------->[to host]--->|
+ | |
+ v |
+ if (MODE == 6)---------------------------------->[strip]----->|
+ | |
+ v |
+ if (!WRAPPED |
+ & WRONG_RING_ID)-------------------------------------------|--->|
+ | | |
+ v | |
+ if (MODE == 0,1,2,3)------------------------------------------|--->|
+ | | |
+ v | |
+ if (DA MATCH)--------------->if !(SA MATCH)----->[to host]--->| |
+ | | | |
+ | v | |
+ | if (unicast)------->[to host]--->| |
+ | | | |
+ | v | |
+ if (SA MATCH)-------------------->[strip]-------------------->| |
+ | | |
+ | | v
+ |--------------------------->|<-----------------------|----|
+ | |
+ v |
+ if (ttl < 2)------->[strip]----->|
+ | |
+ v |
+ [decrement ttl] |
+ | |
+ [fwd pkt to tb] |
+ | v
+ |<-----------------------|
+ v
+ [back to top]
+
+ Notes: Host is responsible for discarding CRC errored packets.
+ Conditionals (if statements) branch to the right if true
+ and branch down if false.
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 26]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+5.1. Transmission and forwarding with priority
+
+ A node can transmit four types of packets:
+
+ 1. High priority packets from the high priority transit
+ buffer.
+
+ 2. Low priority packets from the low priority transit buffer.
+
+ 3. High priority packets from the host Tx high priority fifo.
+
+ 4. Low priority packets from the host Tx low priority fifo.
+
+ High priority packets from the transit buffer are always sent first.
+ High priority packets from the host are sent as long as the low
+ priority transit buffer is not full. Low priority packets are sent
+ as long as the transit buffer has not crossed the low priority
+ threshold and the SRP-fa rules allow it (my_usage < allowed_usage).
+ If nothing else can be sent, low priority packets from the low
+ priority transit buffer are sent.
+
+ This decision tree is shown in Figure 17.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 27]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ FIGURE 17. SRP transmit flowchart
+
+ if (TB_High has pkt)----------->[send pkt from TB_high]-->|
+ | |
+ v |
+ if (TB_Low full)------------------------------------------|---->|
+ | | |
+ v | |
+ if (Tx_High has pkt)----------->[send pkt from Tx_high]-->| |
+ | | |
+ v | |
+ if (TB_Low > Hi threshold)--------------------------------|---->|
+ | | |
+ v | |
+ if (my_usage >= allowed_usage)----------------------------|---->|
+ | | |
+ v | |
+ if (Tx_Low has pkt)------------>[send pkt from Tx_low]--->| |
+ | | |
+ | | v
+ |<------------------------------------------------|-----|
+ | |
+ v |
+ if (TB_Low has pkt)------------>[send pkt from TB_low]--->|
+ | v
+ |<------------------------------------------------|
+ |
+ v
+ [Go to Top]
+
+ Notes: Conditionals (if statements) branch to the right if true
+ and branch down if false.
+
+5.2. Wrapping of Data
+
+ Normally, transmitted data is sent on the same ring to the downstream
+ neighbor. However, if a node is in the wrapped state, transmitted
+ data is sent on the opposite ring to the upstream neighbor.
+
+6. SRP-fa Rules Of Operation
+
+ The SRP-fa governs access to the ring. The SRP-fa only applies to
+ low priority traffic. High priority traffic does not follow SRP-fa
+ rules and may be transmitted at any time as long as there is
+ sufficient transit buffer space.
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 28]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ The SRP-fa requires three counters which control the traffic
+ forwarded and sourced on the SRP ring. The counters are my_usage
+ (tracks the amount of traffic sourced on the ring), forward_rate
+ (amount of traffic forwarded on to the ring from sources other than
+ the host) and allowed_usage (the current maximum transmit usage for
+ that node).
+
+ With no congestion all nodes build up allowed usage periodically.
+ Each node can send up to max_usage. Max_usage is a per node
+ parameter than limits the maximum amount of low priority traffic a
+ node can send.
+
+ When a node sees congestion it starts to advertise its my_usage which
+ has been low pass filtered (lp_my_usage).
+
+ Congestion is measured by the transit buffer depth crossing a
+ congestion threshold.
+
+ A node that receives a non-null usage message (rcvd_usage) will set
+ its allowed usage to the value advertised. However, if the source of
+ the rcvd_usage is the same node that received it then the rcvd_usage
+ shall be treated as a null value. When comparing the rcvd_usage
+ source address the ring ID of the usage packet must match the
+ receiver's ring ID in order to qualify as a valid compare. The
+ exception is if the receive node is in the wrap state in which case
+ the usage packet's ring ID is ignored.
+
+ Nodes that are not congested and that receive a non-null rcvd_usage
+ generally propagate rcvd_usage to their upstream neighbor else
+ propagate a null value of usage (all 1's). The exception is when an
+ opportunity for local reuse is detected. Additional spatial reuse
+ (local reuse) is achieved by comparing the forwarded rate (low pass
+ filtered) to allow_usage. If the forwarded rate is less than the
+ allowed usage, then a null value is propagated to the upstream
+ neighbor.
+
+ Nodes that are congested propagate the smaller of lp_my_usage and
+ rcvd_usage.
+
+ Convergence is dependent upon number of nodes and distance.
+ Simulation has shown simulation convergence within 100 msec for rings
+ of several hundred miles.
+
+
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 29]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+6.1. SRP-fa pseudo-code
+
+ A more precise definition of the fairness algorithm is shown below:
+
+Variables:
+
+lo_tb_depth low priority transit buffer depth
+
+my_usage count of octets transmitted by host
+lp_my_usage my_usage run through a low pass filter
+my_usage_ok flag indicating that host is allowed to transmit
+
+allow_usage the fair amount each node is allowed to transmit
+
+fwd_rate count of octets forwarded from upstream
+lp_fwd_rate fwd_rate run through a low pass filter
+
+congested node cannot transmit host traffic without the TB buffer
+ filling beyond its congestion threshold point.
+
+rev_usage the usage value passed along to the upstream neighbor
+
+Constants:
+
+MAX_ALLOWANCE = configurable value for max allowed usage for this node
+
+DECAY_INTERVAL = 8000 octet times @ OC-12, 32,000 octet times @ OC-48
+
+AGECOEFF = 4 // Aging coeff for my_usage and fwd_rate
+
+LP_FWD = 64 // Low pass filter for fwd_rate
+LP_MU = 512 // Low pass filter for my usage
+LP_ALLOW = 64 // Low pass filter for allow usage auto increment
+
+NULL_RCVD_INFO = All 1's in rcvd_usage field
+
+TB_LO_THRESHOLD // TB depth at which no more lo-prio host traffic
+ // can be sent
+
+MAX_LRATE = AGECOEFF * DECAY_INTERVAL = 128,000 for OC-48, 32000 for
+ OC-12
+
+
+
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 30]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+THESE ARE UPDATED EVERY CLOCK CYCLE:
+=====================================
+
+my_usage is incremented by 1 for every octet that is
+ transmitted by the host (does not include data
+ transmitted from the Transit Buffer).
+
+fwd_rate is incremented by 1 for every octet that enters the
+ Transit Buffer
+
+if ((my_usage < allow_usage) &&
+ !((lo_tb_depth > 0) && (fwd_rate < my_usage)) &&
+ (my_usage < MAX_ALLOWANCE))
+ // true means OK to send host packets
+ my_usage_ok = true;
+
+
+UPDATED WHEN USAGE_PKT IS RECEIVED:
+===================================
+
+if (usage_pkt.SA == my_SA) &&
+ [(usage_pkt.RI == my_RingID) || (node_state == wrapped)]
+ rcvd_usage = NULL_RCVD_INFO;
+else
+ rcvd_usage = usage_pkt.usage;
+
+
+THE FOLLOWING IS CALCULATED EVERY DECAY_INTERVAL:
+==================================================
+
+congested = (lo_tb_depth > TB_LO_THRESHOLD/2)
+
+lp_my_usage = ((LP_MU-1) * lp_my_usage + my_usage) / LP_MU
+
+my_usage is decremented by min(allow_usage/AGECOEFF, my_usage/AGECOEFF)
+
+lp_fwd_rate = ((LP_FWD-1) * lp_fwd_rate + fwd_rate) / LP_FWD
+
+fwd_rate is decremented by fwd_rate/AGECOEFF
+
+(Note: lp values must be calculated prior to decrement of non-lp
+values).
+
+if (rcvd_usage != NULL_RCVD_INFO)
+ allow_usage = rcvd_usage;
+else
+ allow_usage += (MAX_LRATE - allow_usage) / (LP_ALLOW);
+
+
+
+
+Tsiang & Suwala Informational [Page 31]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+if (congested)
+ {
+ if (lp_my_usage < rcvd_usage)
+ rev_usage = lp_my_usage;
+ else
+ rev_usage = rcvd_usage;
+ }
+else if ((rcvd_usage != NULL_RCVD_INFO) &&
+ (lp_fwd_rate > allow_usage)
+ rev_usage = rcvd_usage;
+else
+ rev_usage = NULL_RCVD_INFO
+
+if (rev_usage > MAX_LRATE)
+ rev_usage = NULL_RCVD_INFO;
+
+6.2. Threshold settings
+
+ The low priority transit buffer (TB_LO_THRESHOLD) is currently sized
+ to about 4.4 msec or 320 KB at OC12 rates. The TB_HI_THRESHOLD is
+ set to about 870 usec higher than the TB_LO_THRESHOLD or at 458 KB at
+ OC12 rates.
+
+ The high priority transit buffer needs to hold 2 to 3 MTUs or about
+ 30KB.
+
+7. SRP Synchronization
+
+ Each node operates in "free-run" mode. That is, the receive clock is
+ derived from the incoming receive stream while the transmit clock is
+ derived from a local oscillator. This eliminates the need for
+ expensive clock synchronization as required in existing SONET
+ networks. Differences in clock frequency are accommodated by
+ inserting a small amount of idle bandwidth at each nodes output.
+
+ The clock source for the transmit clock shall be selected to deviate
+ by no more than 20 ppm from the center frequency. The overall
+ outgoing rate of the node shall be rate shaped to accommodate the
+ worst case difference between receive and transmit clocks of adjacent
+ nodes. This works as follows:
+
+ A transit buffer slip count (tb_cnt) keeps track of the amount of
+ octets inserted into the TB minus the amount of octets transmitted
+ and is a positive integer.
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 32]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ To account for a startup condition where a packet is being inserted
+ into an empty TB and the node was otherwise idle the tb_cnt is reset
+ if the transmit interface is idle. Idle is defined as no data being
+ sent even though there is opportunity to send (i.e. the transmit
+ interface is not prohibited from transmitting by the physical layer).
+
+ An interval counter defines the sample period over which rate shaping
+ is performed. This number should be sufficiently large to get an
+ accurate rate shaping.
+
+ A token_bucket counter implements the rate shaping and is a signed
+ integer. We increment this counter by one of two fixed values called
+ quantums each sample period. Quantum1 sets the rate at (Line_rate -
+ Delta) where delta is the clock inaccuracy we want to accommodate.
+
+ Quantum2 sets the rate at (Line_rate + Delta). If at the beginning
+ of a sample period, tb_cnt >= sync_threshold, then we set the rate to
+ Quantum2. This will allow us to catch up and causes the TB slip count
+ to eventually go < sync_threshold. If tb_cnt is < sync_threshold
+ then we set the rate to Quantum1.
+
+ When the input rate and output rates are exactly equal, the tb_cnt
+ will vary between sync_threshold > tb_cnt >= 0. This will vary for
+ each implementation dependent upon the burst latencies of the design.
+ The sync_threshold value should be set so that for equal transmit and
+ receive clock rates, the transmit data rate is always Line_rate-Delta
+ and will be implementation dependent.
+
+ The token_bucket is decremented each time data is transmitted. When
+ token_bucket reaches a value <= 0, a halt_transmit flag is asserted
+ which halts further transmission of data (halting occurs on a packet
+ boundary of course which can cause token_bucket to become a negative
+ number).
+
+7.1. SRP Synchronization Examples
+
+ Assume an interval of 2^^18 or 262144 clock cycles. A Quantum1 value
+ must be picked such that the data rate will = (LINE_RATE - DELTA). A
+ Quantum2 value must be picked and used if the tb_cnt shows that the
+ incoming rate is greater than the outgoing rate and is = (LINE_RATE +
+ DELTA). Assume that the source of the incoming and outgoing rate
+ clocks are +/- 100 ppm.
+
+ For an OC12c SPE rate of 600 Mbps and a system clock rate of 800 Mbps
+ (16 bits @ 50 Mhz). The system clock rate is the rate at which the
+ system transmits bytes to the framer (in most cases the framer
+ transmit rate is asynchronous from the rate at which the system
+ transfers data to the framer).
+
+
+
+Tsiang & Suwala Informational [Page 33]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ Quantum1/Interval * 800 Mbps = 600 Mbps(1 - Delta)
+ Quantum1 = Interval * (600/800) * (1 - Delta)
+ Quantum1 = Interval * (600/800) * (1 - 1e-4) = 196588
+
+ Quantum2/Interval * 800 Mbps = 600 Mbps(1 + Delta)
+ Quantum2 = Interval * (600/800) * (1 + Delta)
+ Quantum2 = Interval * (600/800) * (1 + 1e-4) = 196628
+
+ Note: The actual data rate for OC-12c is 599.04 Mbps.
+
+8. IPS Protocol Description
+
+ An SRP ring is composed of two counter-rotating, single fiber rings.
+ If an equipment or fiber facility failure is detected, traffic going
+ towards and from the failure direction is wrapped (looped) back to go
+ in the opposite direction on the other ring. The wrap around takes
+ place on the nodes adjacent to the failure, under software control.
+ This way the traffic is re-routed from the failed span.
+
+ Nodes communicate between themselves using IPS signaling on both
+ inner and outer ring.
+
+ The IPS octet contains specific protection information. The format of
+ the IPS octet is as follows:
+
+ FIGURE 18. IPS Octet format:
+
+ 0-3 IPS Request Type
+
+ 1101 - Forced Switch (FS)
+ 1011 - Signal Fail (SF)
+ 1000 - Signal Degrade (SD)
+ 0110 - Manual Switch (MS)
+ 0101 - Wait to Restore (WTR)
+ 0000 - No Request (IDLE)
+
+ 4 Path indicator
+
+ 0 - short (S)
+ 1 - long (L)
+
+ 5-7 Status Code
+
+ 010 - Protection Switch Completed -traffic Wrapped (W)
+ 000 - Idle (I)
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 34]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ The IPS control messages are shown in this document as:
+
+ {REQUEST_TYPE, SOURCE_ADDRESS, WRAP_STATUS, PATH_INDICATOR}
+
+8.1. The IPS Request Types
+
+ The following is a list of the request types, from the highest to the
+ lowest priority. All requests are signaled using IPS control
+ messages.
+
+ 1. Forced Switch (FS - operator originated)
+
+ This command performs the ring switch from the working channel
+ to the protection, wrapping the traffic on the node at which
+ the command is issued and at the adjacent node to which the
+ command is destined. Used for example to add another node to
+ the ring in a controlled fashion.
+
+ 2. Signal Fail (SF - automatic)
+
+ Protection caused by a media "hard failure" or SRP keep- alive
+ failure. SONET examples of SF triggers are: Loss of Signal
+ (LOS), Loss of Frame (LOF), Line Bit Error Rate (BER) above a
+ preselected SF threshold, Line Alarm Indication Signal (AIS).
+ Note that the SRP keep-alive failure provides end-to-end
+ coverage and as a result SONET Path triggers are not necessary.
+
+ 3. Signal Degrade (SD - automatic)
+
+ Protection caused by a media "soft failure". SONET example of a
+ SD is Line BER or Path BER above a preselected SD threshold.
+
+ 4. Manual Switch (MS - operator originated)
+
+ Like the FS, but of lower priority. Can be used for example to
+ take down the WTR.
+
+ 5. Wait to Restore (WTR - automatic)
+
+ Entered after the working channel meets the restoration
+ threshold after an SD or SF condition disappears. IPS waits WTR
+ timeout before restoring traffic in order to prevent protection
+ switch oscillations.
+
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 35]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+8.2. SRP IPS Protocol States
+
+ Each node in the IPS protocol is in one of the following states for
+ each of the rings:
+
+8.2.1. Idle
+
+ In this mode the node is ready to perform the protection switches and
+ it sends to both neighboring nodes "idle" IPS messages, which include
+ "self" in the source address field {IDLE, SELF, I, S}
+
+8.2.2. Pass-through
+
+ Node participates in a protection switch by passing the wrapped
+ traffic and long path signaling through itself. This state is entered
+ based on received IPS messages. If a long path message with not null
+ request is received and if the node does not strip the message (see
+ Protocol Rules for stripping conditions) the node decrements the TTL
+ and retransmits the message without modification. Sending of the
+ Idle messages is stopped in the direction in which the message with
+ not null request is forwarded.
+
+8.2.3. Wrapped
+
+ Node participates in a protection switch with a wrap present. This
+ state is entered based on a protection request issued locally or
+ based on received IPS messages.
+
+8.3. IPS Protocol Rules
+
+8.3.1. SRP IPS Packet Transfer Mechanism
+
+ R T.1:
+
+ IPS packets are transferred in a store and forward mode between
+ adjacent nodes (packets do not travel more than 1 hop between nodes
+ at a time). Received packet (payload portion) is passed to software
+ based on interrupts.
+
+ R T.2:
+
+ All IPS messages are sent to the neighboring nodes periodically on
+ both inner and outer rings. The timeout period is configurable 1-600
+ sec (default 1 sec). It is desirable (but not required) that the
+ timeout is automatically decreased by a factor of 10 for the short
+ path protection requests.
+
+
+
+
+
+Tsiang & Suwala Informational [Page 36]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+8.3.2. SRP IPS Signaling and Wrapping Mechanism
+
+ R S.1:
+
+ IPS signaling is performed using IPS control packets as defined in
+ Figure 14 "IPS Packet Format".
+
+ R S.2:
+
+ Node executing a local request signals the protection request on both
+ short (across the failed span) and long (around the ring) paths after
+ performing the wrap.
+
+ R S.3:
+
+ Node executing a short path protection request signals an idle
+ request with wrapped status on the short (across the failed span)
+ path and a protection request on the long (around the ring) path
+ after performing the wrap.
+
+ R S.4:
+
+ A node which is neither executing a local request nor executing a
+ short path request signals IDLE messages to its neighbors on the ring
+ if there is no long path message passing through the node on that
+ ring.
+
+ R S.5:
+
+ Protection IPS packets are never wrapped.
+
+ R S.6:
+
+ If the protocol calls for sending both short and long path requests
+ on the same span (for example if a node has all fibers disconnected),
+ only the short path request should be sent.
+
+ R S.7:
+
+ A node wraps and unwraps only on a local request or on a short path
+ request. A node never wraps or unwraps as a result of a long path
+ request. Long path requests are used only to maintain protection
+ hierarchy. (Since the long path requests do not trigger protection,
+ there is no need for destination addresses and no need for topology
+ maps)
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 37]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ In Figure 19, Node A detects SF (local request/ self-detected
+ request) on the span between Node A and Node B and starts sourcing
+ {SF, A, W, S} on the outer ring and {SF, A, W, L} on the inner ring.
+ Node B receives the protection request from Node A (short path
+ request) and starts sourcing {IDLE, B, W, S} on the inner ring and
+ {SF, B, W, L} on the outer ring.
+
+ FIGURE 19. SRP IPS Signaling
+
+ {SF,A,W,S}
+ -------------------------------
+ | -----X--------------------- |
+ | | fiber | |
+ | v cut {IDLE,B,W,S}| v
+ ----- -----
+ | A | | B |
+ | | | |
+ ----- -----
+ ^ | {SF,A,W,L} i ^ | o {SF,B,W,L}
+ | | n | | u
+ | | n | | t
+ | | e | | e
+ | v r | v r
+
+
+8.4. SRP IPS Protocol Rules
+
+ R P.1:
+
+ Protection Request Hierarchy is as follows (Highest priority to the
+ lowest priority). In general a higher priority request preempts a
+ lower priority request within the ring with exceptions noted as
+ rules. The 4 bit values below correspond to the REQUEST_TYPE field in
+ the IPS packet.
+
+ 1101 - Forced Switch (FS)
+ 1011 - Signal Fail (SF)
+ 1000 - Signal Degrade (SD)
+ 0110 - Manual Switch (MS)
+ 0101 - Wait to Restore (WTR)
+ 0000 - No Request (IDLE): Lowest priority
+
+ R P.2:
+
+ Requests >= SF can coexist.
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 38]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ R P.3:
+
+ Requests < SF can not coexist with other requests.
+
+ R P.4:
+
+ A node always honors the highest of {short path request, self
+ detected request} if there is no higher long path message passing
+ through the node.
+
+ R P.5:
+
+ When there are more requests of priority < SF, the first request to
+ complete long path signaling will take priority.
+
+ R P.6:
+
+ A Node never forwards an IPS packet received by it which was
+ originally generated by the node itself (it has the node's source
+ address).
+
+ R P.7:
+
+ Nodes never forward packets with the PATH_INDICATOR set to SHORT.
+
+ R P.8:
+
+ When a node receives a long path request and the request is >= to the
+ highest of {short path request, self detected request}, the node
+ checks the message to determine if the message is coming from its
+ neighbor on the short path. If that is the case then it does not
+ enter pass-thru and it strips the message.
+
+ R P.9:
+
+ When a node receives a long path request, it strips (terminates) the
+ request if it is a wrapped node with a request >= than that in the
+ request; otherwise it passes it through and unwraps.
+
+ R P.10:
+
+ Each node keeps track of the addresses of the immediate neighbors
+ (the neighbor node address is gleaned from the short path IPS
+ messages).
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 39]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ R P.11:
+
+ When a wrapped node (which initially detected the failure) discovers
+ disappearance of the failure, it enters WTR (user-configurable WTR
+ time-period). WTR can be configured in the 10-600 sec range with a
+ default value of 60 sec.
+
+ R P.12:
+
+ When a node is in WTR mode, and detects that the new neighbor (as
+ identified from the received short path IPS message) is not the same
+ as the old neighbor (stored at the time of wrap initiation), the node
+ drops the WTR.
+
+ R P.13:
+
+ When a node is in WTR mode and long path request Source is not equal
+ to the neighbor Id on the opposite side (as stored at the time of
+ wrap initiation), the node drops the WTR.
+
+ R P.14:
+
+ When a node receives a local protection request of type SD or SF and
+ it cannot be executed (according to protocol rules) it keeps the
+ request pending. (The request can be kept pending outside of the
+ protection protocol implementation).
+
+ R P.15:
+
+ If a local non-failure request (WTR, MS, FS) clears and if there are
+ no other requests pending, the node enters idle state.
+
+ R P.16:
+
+ If there are two failures and two resulting WTR conditions on a
+ single span, the second WTR to time out brings both the wraps down
+ (after the WTR time expires a node does not unwrap automatically but
+ waits till it receives idle messages from its neighbor on the
+ previously failed span)
+
+ R P.17:
+
+ If a short path FS request is present on a given side and a SF/SD
+ condition takes place on the same side, accept and process the SF/SD
+ condition ignoring the FS. Without this rule a single ended wrap
+ condition could take place. (Wrap on one end of a span only).
+
+
+
+
+
+Tsiang & Suwala Informational [Page 40]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+8.5. State Transitions
+
+ Figure 20 shows the simplified state transition diagram for the IPS
+ protocol:
+
+ FIGURE 20. Simplified State Transitions Diagram
+
+ Local FS,SF,SD,MS req.
+ --------- or Rx{REQ,SRC,W,S} from mate
+ | IDLE |-------------------------------------------
+ | |<---------------------------------------- |
+ --------- Local REQ clears | |
+ ^ | or Rx{IDLE,SRC,I,S} | |
+ | | | |
+ | | | |
+ | | | |
+ | | | |
+Rx{IDLE,SRC,I,S}| | Rx{REQ,SRC,W,L} | |
+ | | | |
+ | | | |
+ | v Local FS,SF,SD,MS REQ > Active req. | v
+ --------- or Rx{REQ,SRC,W,S},REQ > Active req. ---------
+ | PASS |------------------------------------>| WRAPPED |
+ | THRU |<------------------------------------| |
+ --------- ---------
+ Forwards Tx{REQ,SELF,W,S} for local REQ
+ {REQ,SRC,W,L} Tx{IDLE,SELF,W,S} for mate REQ
+ & Tx{REQ,SELF,W,L}
+
+ Legend: Mate = node on the other end of the affected span
+ REQ = {FS | SF | SD | MS}
+
+8.6. Failure Examples
+
+8.6.1. Signal Failure - Single Fiber Cut Scenario
+
+ Sample scenario in a ring of four nodes A, B, C and D, with
+ unidirectional failure on a fiber from A to B, detected on B. Ring is
+ in the Idle state (all nodes are Idle) prior to failure.
+
+ Signal Fail Scenario
+
+ 1. Ring in Idle, all nodes transmit (Tx) {IDLE, SELF, I, S} on both
+ rings (in both directions)
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 41]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ FIGURE 21. An SRP Ring with outer ring fiber cut
+
+ fiber cut
+ ---------X-----------------------------
+ | ----------------------------------- |
+ | | | |
+ | v | v
+ ----- -----
+ | A | | B |
+ | | | |
+ ----- -----
+ ^ | ^ |
+ o | | i | |
+ u | | n | |
+ t | | n | |
+ e | | e | |
+ r | | r | |
+ | v | v
+ ----- -----
+ | D | | C |
+ | | | |
+ ----- -----
+ | | | |
+ | | | |
+ | ----------------------------------- |
+ ---------------------------------------
+
+
+ 2. B detects SF on the outer ring, transitions to Wrapped state
+ (performs a wrap), Tx towards A on the inner ring/short path:
+ {SF, B, W, S} and on the outer ring/long path: Tx {SF, B, W, L}
+
+ 3. Node A receives protection request on the short path,
+ transitions to Wrapped state, Tx towards B on short path:
+ {IDLE, A, W, S} (message does not go through due to the
+ failure) and on the long path: Tx {SF, A, W, L}
+
+ 4. As the nodes D and C receive a switch request, they enter a
+ pass-through mode (in each direction) which mean they stop
+ sourcing the Idle messages and start passing the messages
+ between A an B
+
+ 5. Steady state is reached
+
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 42]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ Signal Fail Clears
+
+ 1. SF on B clears, B does not unwrap, sets WTR timer, Tx {WTR, B,
+ W, S} on inner and Tx {WTR, B, W, L}
+
+ 2. Node A receives WTR request on the short path, does not unwrap,
+ Tx towards B on short path: {IDLE, A, W, S} (message does not
+ go through due to the failure) and on the long path: Tx {WTR,
+ A, W, L}
+
+ 3. Nodes C and D relay long path messages without changing the IPS
+ octet
+
+ 4. Steady state is reached
+
+ 5. WTR times out on B. B transitions to idle state (unwraps) Tx
+ {IDLE, B, I, S} on both inner and outer rings
+
+ 6. A receives Rx {IDLE, B, I, S} and transitions to Idle
+
+ 7. As idle messages reach C and D the nodes enter the idle state
+ (start sourcing the Idle messages)
+
+ 8. Steady state it reached
+
+8.6.2. Signal Failure - Bidirectional Fiber Cut Scenario
+
+ Sample scenario in a ring of four nodes A, B, C and D, with a
+ bidirectional failure between A and B. Ring is in the Idle state
+ (all nodes are Idle) prior to failure.
+
+ Signal Fail Scenario
+
+ 1. Ring in Idle, all nodes transmit (Tx) {IDLE, SELF, I, S} on
+ both rings (in both directions)
+
+ 2. A detects SF on the outer ring, transitions to Wrapped state
+ (performs a wrap), Tx towards B on the inner ring/short path:
+ {SF, A, W, S} and on the outer ring/long path: Tx {SF, A, W, L}
+
+ 3. B detects SF on the outer ring, transitions to Wrapped state
+ (performs a wrap), Tx towards A on the inner ring/short path:
+ {SF, B, W, S} and on the outer ring/long path: Tx {SF, B, W, L}
+
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 43]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ FIGURE 22. An SRP Ring with bidirectional fiber cut
+
+ fiber cut
+ ---------X-----------------------------
+ | -------X--------------------------- |
+ | | fiber cut | |
+ | v | v
+ ----- -----
+ | A | | B |
+ | | | |
+ ----- -----
+ ^ | ^ |
+ o | | i | |
+ u | | n | |
+ t | | n | |
+ e | | e | |
+ r | | r | |
+ | v | v
+ ----- -----
+ | D | | C |
+ | | | |
+ ----- -----
+ | | | |
+ | | | |
+ | ----------------------------------- |
+ ---------------------------------------
+
+ 4. As the nodes D and C receive a switch request, they enter a
+ pass-through mode (in each direction) which mean they stop
+ sourcing the Idle messages and start passing the messages
+ between A an B
+
+ 5. Steady state is reached
+
+ Signal Fail Clears
+
+ 1. SF on A clears, A does not unwrap, sets WTR timer, Tx {WTR, A,
+ W, S} towards B and Tx {WTR, A, W, L} on the long path
+
+ 2. SF on B clears, B does not unwrap. Since it now has a short
+ path WTR request present from A it acts upon this request. It
+ keeps the wrap, Tx {IDLE, B, W, S} towards A and Tx {WTR, B, W,
+ L} on the long path
+
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 44]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ 3. Nodes C and D relay long path messages without changing the IPS
+ octet
+
+ 4. Steady state is reached
+
+ 5. WTR times out on A. A enters the idle state (drops wraps) and
+ starts transmitting idle in both rings
+
+ 6. B sees idle request on short path and enters idle state
+
+ 7. Remaining nodes in the ring enter the idle state
+
+ 8. Steady state is reached
+
+8.6.3. Failed Node Scenario
+
+ FIGURE 23. An SRP Ring with a failed node
+
+ ---------------------------------------
+ | ----------------------------------- |
+ | | | |
+ | v | v /
+ ----- ----/
+ | A | | C/| failed
+ | | | / | node C
+ ----- -/---
+ ^ | /^ |
+ o | | i | |
+ u | | n | |
+ t | | n | |
+ e | | e | |
+ r | | r | |
+ | v | v
+ ----- -----
+ | D | | B |
+ | | | |
+ ----- -----
+ | | | |
+ | | | |
+ | ----------------------------------- |
+ ---------------------------------------
+
+ Sample scenario in a ring where node C fails. Ring is in the Idle
+ state (all nodes are Idle) prior to failure.
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 45]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ Node Failure (or fiber cuts on both sides of the node)
+
+ 1. Ring in Idle, all nodes transmit (Tx) {IDLE, SELF, I, S} on
+ both rings (in both directions)
+
+ 2. Based on the source field of the idle messages, all nodes
+ identify the neighbors and keep track of them
+
+ 3. B detects SF on the outer ring, transitions to Wrapped state
+ (performs a wrap), Tx towards C on the inner ring/short path:
+ {SF, B, W, S} and on the outer ring/long path: Tx {SF, B, W, L}
+
+ 4. A detects SF on the inner ring, transitions to Wrapped state
+ (performs a wrap), Tx towards C on the outer ring/short path:
+ {SF, A, W, S} and on the inner ring/long path: Tx {SF, A, W, L}
+
+ 5. As the nodes on the long path between A and B receive a SF
+ request, they enter a pass-through mode (in each direction),
+ stop sourcing the Idle messages and start passing the messages
+ between A an B
+
+ 6. Steady state is reached
+
+ Failed Node and One Span Return to Service
+
+ Note: Practically the node will always return to service with one
+ span coming after the other (with the time delta potentially close to
+ 0). Here, a node is powered up with the fibers connected and fault
+ free.
+
+ 1. Node C and a span between A and C return to service (SF between
+ A and C disappears)
+
+ 2. Node C, not seeing any faults starts to source idle messages
+ {IDLE, C, I, S} in both directions.
+
+ 3. Fault disappears on A and A enters a WTR (briefly)
+
+ 4. Node A receives idle message from node C. Because the long path
+ protection request {SF, B, W, L} received over the long span is
+ not originating from the short path neighbor (C), node A drops
+ the WTR and enters a PassThrough state passing requests between
+ C and B
+
+ 5. Steady state is reached
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 46]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ Second Span Returns to Service
+
+ The scenario is like the Bidirectional Fiber Cut fault clearing
+ scenario.
+
+8.6.4. Bidirectional Fiber Cut and Node Addition Scenarios
+
+ FIGURE 24. An SRP Ring with a failed node
+
+ wrap
+ ----->|--------------------------------
+ | -<--|------------------------------ |
+ | | | |
+ | v | v
+ ----- ----
+ | A | | C | Added
+ | | | | node
+ ----- -----
+ ^ | ^ |
+ o | | i | |
+ u | | n | |
+ t | | n | |
+ e | | e --- wrap
+ r | | r ^ |
+ | v | v
+ ----- -----
+ | D | | B |
+ | | | |
+ ----- -----
+ | | | |
+ | | | |
+ | ----------------------------------- |
+ ---------------------------------------
+
+ Sample scenario in a ring where initially nodes A and B are
+ connected. Subsequently fibers between the nodes A and B are
+ disconnected and a new node C is inserted.
+
+ Bidirectional Fiber Cut
+
+ 1. Ring in Idle, all nodes transmit (Tx) {IDLE, SELF, I, S} on
+ both rings (in both directions)
+
+ 2. Fibers are removed between nodes A and B
+
+ 3. B detects SF on the outer ring, transitions to Wrapped state
+ (performs a wrap), Tx towards A on the inner ring/short path:
+ {SF, B, W, S} and on the outer ring/long path: Tx {SF, B, W, L}
+
+
+
+Tsiang & Suwala Informational [Page 47]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ 4. A detects SF on the inner ring, transitions to Wrapped state
+ (performs a wrap), Tx towards B on the inner ring/short path:
+ {SF, A, W, S} and on the outer ring/long path: Tx {SF, A, W, L}
+
+ 5. As the nodes on the long path between A and B receive a SF
+ request, they enter a pass-through mode (in each direction),
+ stop sourcing the Idle messages and start passing the messages
+ between A an B
+
+ 6. Steady state is reached
+
+ Node C is Powered Up and Fibers Between Nodes A and C are Reconnected
+
+ This scenario is identical to the returning a Failed Node to Service
+ scenario.
+
+ Second Span Put Into Service
+
+ Nodes C and B are connected. The scenario is identical to
+ Bidirectional Fiber Cut fault clearing scenario.
+
+9. SRP over SONET/SDH
+
+ Although SRP is media independent it is worth noting how SRP is used
+ with a layer 1 media type. SRP over SONET/SDH is the first media type
+ perceived for SRP applications.
+
+ Flag delimiting on SONET/SDH uses the octet stuffing method defined
+ for POS. The flags (0x7E) are packet delimiters required for
+ SONET/SDH links but may not be necessary for SRP on other media
+ types. End of a packet is delineated by the flag which could also be
+ the same as the next packet's starting flag. If the flag (0x7E) or
+ an escape character (0x7D) are present anywhere inside the packet,
+ they have to be escaped by the escape character when used over
+ SONET/SDH media.
+
+ SONET/SDH framing plus POS packet delimiting allows SRP to be used
+ directly over fiber or through an optical network (including WDM
+ equipment).
+
+ SRP may also connect to a SONET/SDH ring network via a tributary
+ connection to a SONET/SDH ADM (Add Drop Multiplexor). The two SRP
+ rings may be mapped into two STS-Nc connections. SONET/SDH networks
+ typically provide fully redundant connections, so SRP mapped into two
+ STS-Nc connections will have two levels of protection. The SONET/SDH
+ network provides layer 1 protection, and SRP provides layer 2
+ protection. In this case it is recommended to hold off the SRP Signal
+ Fail IPS triggers (which correspond to failures which can be
+
+
+
+Tsiang & Suwala Informational [Page 48]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+ protected by SONET/SDH) for about 100 msec in order to allow the
+ SONET/SDH network to protect. Only if a failure persists for over 100
+ msec (indicating SONET/SDH protection failure) should the IPS
+ protection take place.
+
+ Since multiple protection levels over the same physical
+ infrastructure are not very desirable, an alternate way of connecting
+ SRP over a SONET/SDH network is configuring SONET/SDH without
+ protection. Since the connection is unprotected at layer 1, SRP would
+ be the sole protection mechanism.
+
+ Hybrid SRP rings may also be built where some parts of the ring
+ traverse over a SONET/SDH network while other parts do not.
+
+ Connections to a SONET/SDH network would have to be synchronized to
+ network timing by some means. This can be accomplished by locking
+ the transmit connection to the frequency of the receive connection
+ (called loop timing) or via an external synchronization technique.
+
+ Connections made via dark fiber or over a WDM optical network should
+ utilize internal timing as clock synchronization is not necessary in
+ this case.
+
+10. Pass-thru mode
+
+ An optional mode of operation is pass-thru mode. In pass-thru mode,
+ a node transparently forwards data. The node does not source
+ packets, and does not modify any of the packets that it forwards.
+ Data should continue to be sorted into high and low priority transit
+ buffers with high priority transit buffers always emptied first. The
+ node does not source any control packets (e.g. topology discovery or
+ IPS) and basically looks like a signal regenerator with delay (caused
+ by packets that happened to be in the transit buffer when the
+ transition to pass-thru mode occurred).
+
+ A node can enter pass-thru mode because of an operator command or due
+ to a error condition such as a software crash.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 49]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+11. References
+
+ [1] ANSI X3T9 FDDI Specification
+
+ [2] IEEE 802.5 Token Ring Specification
+
+ [3] Bellcore GR-1230, Issue 4, Dec. 1998, "SONET Bidirectional
+ Line-Switched Ring Equipment Generic Criteria".
+
+ [4] ANSI T1.105.01-1998 "Synchronous Optical Network (SONET)
+ Automatic Protection Switching"
+
+ [5] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June
+ 1999.
+
+ [6] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July
+ 1994.
+
+12. Security Considerations
+
+ As in any shared media, packets that traverse a node are available to
+ that node if that node is misconfigured or maliciously configured.
+ Additionally, it is possible for a node to not only inspect packets
+ meant for another node but to also prevent the intended node from
+ receiving the packets due to the destination stripping scheme used to
+ obtain spatial reuse. Topology discovery should be used to detect
+ duplicate MAC addresses.
+
+13. IPR Notice
+
+ The IETF has been notified of intellectual property rights claimed in
+ regard to some or all of the specification contained in this
+ document. For more information consult the online list of claimed
+ rights.
+
+14. Acknowledgments
+
+ The authors would like to acknowledge Hon Wah Chin who came up with
+ the original version of the SRP-fa. Besides the authors, the
+ original conceivers of SRP include Hon Wah Chin, Graeme Fraser, Tony
+ Bates, Bruce Wilford, Feisal Daruwalla, and Robert Broberg.
+
+
+
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 50]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+15. Authors' Addresses
+
+ Comments should be sent to the authors at the following addresses:
+
+ David Tsiang
+ Cisco Systems
+ 170 W. Tasman Drive
+ San Jose, CA 95134
+
+ Phone: (408) 526-8216
+ EMail: tsiang@cisco.com
+
+
+ George Suwala
+ Cisco Systems
+ 170 W. Tasman Drive
+ San Jose, CA 95134
+
+ Phone: (408) 525-8674
+ EMail: gsuwala@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 51]
+
+RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
+
+
+16. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsiang & Suwala Informational [Page 52]
+