(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);
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.
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).
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)
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.
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.
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)
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.
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).
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).
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)
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
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}
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
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.
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
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}
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
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.
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", RFC2615, June
1999.
[6] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC1662, 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.
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
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 RFCEditor function is currently provided by the
Internet Society.