70 likes | 214 Views
I-TAG. A multiplexing tag for service instance scaling in Provider Bridged Networks Mick Seaman mick_seaman@ieee.org. I-TAG. Purpose Architecture Format Context. ITAG : Purpose. Allow upto 2 20 service instances in a PBN Particularly to address the E-LINE reqmt
E N D
I-TAG A multiplexing tag forservice instance scalingin Provider Bridged Networks Mick Seaman mick_seaman@ieee.org
I-TAG • Purpose • Architecture • Format • Context Service instance multiplexing
ITAG : Purpose • Allow upto 220 service instances in a PBN • Particularly to address the E-LINE reqmt • Use for E-LAN, E-TREE optional/as reqd(more later on benefits of choice) • Leverages existing solutions • Complements .1Q, .1ad, .1D • GVRP, GMRP • No major new protocols required for scaling Service instance multiplexing
ITAG : Architecture I-tagging systems are “end-stations” on a provider backbone or core network. The backbone can be either bridged (.1D) or virtual bridged (.1Q /.1ad) If backbone is .1Q then tagging, detagging (ingress and egress) rules are exactly as they are today Tag can be added/not added and tag value dependent on frame C-VID just as for “dual bridge model” in .1Q <<see Paul Bottorff’s slides from Monday for diagram>> Service instance multiplexing
I-TAG : Format (1) • I-TAG EtherType (16 bits) • I-TAG TCI (Tag Control Info, i.e. version, flags8 bits) • PRI/DE (priority, drop eligible 4 bits) • SID (Service Instance ID – 20 bits) • User DA (Destn. Address of conveyed ‘frame’ – 48 bits) • User SA (Source Address of conveyed ‘frame’ – 48 bits) 16 + 128 bits total Service instance multiplexing
I-TAG : Format (2) Service instance multiplexing
I-TAG : Context Service instance multiplexing