c.收端如无本地高优先级请求开blocked端口 d.收端如无本地高优先级请求停发R-APS e. 收端按需执行flush DB Note：环上可以存在多个FS,相互独立，可能导致segmentation的问题，需要使用者自行维护 10.2.5.1 Forced switch – Clearing Clear 命令，端口保持block，直到RPL block；持续发NR,直到收到NRRB; Revertive behavior Owner收到NR,进入WTB,WTB超时，block RPL,发NRRB,flush DB 其它节点收到NRRB,开blocked-no-failed端口，flush db Non-revertive behavior Owner收到NR,无动作，收到clear命令，block rpl port,发nrrb,fush db 其它节点收到NRRB,开blocked-no-failed端口，flush db
10.3 R-APS format
DA:01-19-A7-00-00-[Ring ID], SA: Bridge mac or port mac? Ethernet OAM OpCode 40
R-APS info 32 octets，用了8个，保留24个octets
首字节高4bit,request/state
首字节低4位– sub-code,对request/state进一步解释
1. 如request/state是1110 event
a. Sub-code 0000 表示flush request b. 其它值保留
2. 如request/state是其他值，sub-code传0，忽略接收
第二个字节status
RB 标示RPL是否block，1 block，0 unblock
DNF标示收到消息是否执行flush DB，1 不执行，0执行
BPR，Blocked port reference，标识那个端口block，0 端口0， 1端口1，If both ring links are blocked, the encoded value can be either value Reserved 5 bit 保留
3-8字节Node id，即节点的mac
Reserved 24 bit 保留，传0，接收忽略
10.4 Failure of protocol defect
收到的R-APS包可能会有错，比如owner收到NRRB但node id又不是自己，---配置错，环上配了多个RPL owner，有个在8021里定义的检测机制，failureof protocol – provisioning mismatch (FOP-PM)捕捉并通知设备故障管理进程。
Appendix IRing protection network objectives
No loop,keep monitoring eth layer ring kink, inform SD or SF;Server layer SD, SF inform;not contend with server layer;recovery from sing link failure;recovery sing node failure;multi-failure;operate under all network load conditions;shall be independent of the capability of the server layer; Support multi ring OAM message format
The protection process shall be deterministic Tiny BW consuming
No specific requirement for relay and filter No limitation on num. of ring node(16-255) administratively triggered switchover Revertive mode Non-revertive mode
Single node or link,switch time < 50ms Holdoff time
configurable wait-to-restore times reversion time less than 50ms
administratively triggered switchover,switch time <50ms
Appendix IIEthernet ring network objectives
描述ERPS的目标，没有太多实质性内容
物理层可以有一些保护机制，如SDH VCs 用GFP mapping，LAG,8032和其无关。
Appendix IIIRing protection scenarios Scenario A – Single link failure(p56) Failure:
A．既然RPL口block了，A会G发的NR,RB，消息吗？从图上看，会，既然RPL端口都block了，R-APS channel都block，怎么还会收到NR,RB呢？
C. flush DB,针对的对象应是所有被保护的vlan，其它vlan应不受影响。，故障口还会清掉node id, bpr
D.收到NR,清node id, bpr
F. 其它节点会收到2次故障节点发送的SF消息，近端和远端，每次收到都会触发flush FDB.
发生单断，整个环要经历C,D,E,F,G五个阶段最后稳定到G状态下 B发生单断 故障2端经历4个动作，阻塞端口（after hold time expires），发送SF，flush db,清空nodeid,bpr,跨越C,D,E三个阶段，可以理解为，先阻塞端口，后继三个动作并行完成 E阶段，所有收到SF的节点flush db,rpl owner和neighbor开阻塞端口 F阶段，SF消息继续传播，穿过原来阻塞的节点，所有节点收到SF时，将再次flush db
Reversion:
E: 断点link恢复后
故障相关节点：
进入guard timer,各自发送NR,期间不响应接收到的R-APS，端口保持阻塞 清node id ,bpr
Non-revertive恢复，在owner上执行clear命令，block rpl, send nrrb,flush fdb,其它和revertive一样
Scenario B – Single unidirectional link failure(P59) 单断，故障和恢复类似双断 单断，即收无光，只在故障节点动作，邻接节点无动作 注意步骤F, 当owner和neighbor开block端口后，所有node会第二次收到SF, 对于其他节点node id,bpr没有改变，所以不发生第二次flush DB，但对于故障节点，由于它之前发生故障时清空了node id ,bpr，此时收到自己的SF，会再次flush DB.
Scenario C – RPL failure 区别在于SF with DNF
Scenario D – Multiple failure case – Recovery NR,guard time,先开2个小端口 收到SF，block-unfailed端口打开 收到SF,Wtr停止
Guard timer后，开始处理收到的NR, 并根据NR中Node id和自己node id大小
比对，决定是否unblock端口；如果收到的node id比自己大，则开放端口,停发NR
Node id大的节点收到NRRB后，停止发NR, 开端口
其它节点： 所有节点收到NR后，清node id, bpr Owner触发WTR,wtr超时，阻塞端口，发送NRRB 所有节点收到NRRB后，flush, neighbor收到nrrb，阻塞端口
Appendix IVConsiderations for the different timers(P64)
IV.1 State machine use of timers
描述各种会用到时钟及何种时钟的场景
e.描述owner进pending状态的两种情况，不知何意 1.收到NR，此时如果是 Revertive,触发WTR,进pending 进pending,直到clear 2.WTR触发 Clear ms,sf?还有其它情况吗？
f. clear after,ms/fs, pending ->protection之前启动guard g. have a ms, receive ms, 进pending之前启动guard h．owner has a ms,收到一个ms或clear，启动wtb
IV.2 Guard timer use to block outdated R-APS messages
举了一个为什么要用guard的例子，简单归结为用guard过滤掉outdated信息 否则可能引起环路
比如断点恢复，断点可能收到过期的SF，开non-failed的端口，导致环路
相关推荐：
loading