100 likes | 212 Views
802.17c Protected Inter-Ring Connection. Rafi Ram - Corrigent Systems January 2007. 802.17c Proposed Requirements. Backwards compatible with non-802.17c stations Support rings interconnect through dual-station homing Provide sub 50msec protection
E N D
802.17cProtected Inter-Ring Connection Rafi Ram - Corrigent Systems January 2007
802.17c Proposed Requirements • Backwards compatible with non-802.17c stations • Support rings interconnect through dual-station homing • Provide sub 50msec protection • Allow for hash based load balancing using both stations • The load balancing shall allow unicast forwarding (prevent persistent flooding) • Support for local tributary interfaces in interconnecting stations • Prevent loops in normal and protection states, and during the transient process between the states
802.17c Proposed Requirements (cont’) • Support both point-to-point and multi-point-to-multi-point services • Support network topology of collector ring with multiple subtending rings • Support for efficient selective MAC table flush • Attend the MAC table scalability issue • Provide maintenance commands (e.g. manual switch-over) • Allow implementation of interconnecting station as two separate stations with back-to-back connections
Suggested Solution • Backwards compatible with non-802.17c stations • Transparent for non-interconnecting stations • Minimal overhead of provisioning, protocol messages, database and state-machines • The basic suggestion resolve all proposed requirements (with the exception of static MAC entries) • An additional enhancement can be suggested to addresses the MAC table scalability issue
Definitions • Stations A & B are members of a protection group (PG) for interconnect in ring 1 with ring 2 • Stations A & B are members of a (different) protection group for interconnect in ring 1 with ring 3 • Each protection group is provisioned with a ring wide unique identifying index – PGI • One of the stations in a PG is provisioned as the “0” member, and the other as the “1” member PGM = protection group member
Provisioning Example • PGI 101 is provisioned in ring 1 for interconnect with ring 2 • station A is provisioned in ring 1 as PGI member 101.0 • station B is provisioned in ring 1 as PGI member 101.1 • PGI 102 is provisioned in ring 1 for interconnect with ring 3 • station A is provisioned in ring 1 as PGI member 102.0 • station B is provisioned in ring 1 as PGI member 102.1 There is no need to provision stations A & B as PG in ring 2 or 3
Frame Forwarding • The forwarding of frames between the rings through the interconnect shall be based on the switching method implemented by the station client (layer 2 or layer 3) • For example, in case of layer 2 switching : • MAC table learning shall be done in the inter-connecting station on frames forwarded between the rings • Multicast and broadcast shall be forwarded though interconnect • Unicast frames with relevant matching entries in the MAC table shall also be forwarded though the interconnect
Load Balancing • To allow for load balancing, the protection group members shall use hash function to distribute the inter-connecting traffic between them • The hash function should be flow based • For example, if both inter-connecting member stations are active then : • the “0” member station shall not forward (discard) frames with odd hash result • the “1” member station shall not forward frames with even hash result
PGM Status Message • Protection group member status messages are used to advertises the state of the interconnect functionality to the mate PG member • The PGM status message is a broadcast frame. The message can be a new control type or a new OAM type • The frame shall contains multiple entries, an entry per protection group that the station participates • A message entry consists of the PG index, “0” or “1” configuration and interconnect functionality state