1. I-TAG
A multiplexing tag for service instance scaling in Provider Bridged Networks
Mick Seaman

2. Service instance multiplexing
I-TAG
Purpose
Architecture
Format
Context
802.1 July ‘04
Service instance multiplexing

3. 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
802.1 July ‘04
Service instance multiplexing

4. 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>>
802.1 July ‘04
Service instance multiplexing

5. Service instance multiplexing
I-TAG : Format (1)
I-TAG EtherType (16 bits)
I-TAG TCI (Tag Control Info, i.e. version, flags 8 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)
bits total
802.1 July ‘04
Service instance multiplexing

6. Service instance multiplexing
I-TAG : Format (2)
802.1 July ‘04
Service instance multiplexing

7. Service instance multiplexing
I-TAG : Context
802.1 July ‘04
Service instance multiplexing