Subject: VLAN ID functions [was: 802.1ad Customer FCS Retention]

From: [email-masked]
Date: Thu, 11 Dec 2003 10:47:45 +0100

Neil,

The VLAN ID has two functions:
1) a means to identify an ETH VPN and instantiate an ETH flow domain 
fragment (G.8010)
2) a means to identify and instantiate an ETH component link.

In today's ethernet these two fucntions are often locked together.
 
It would however be possible to use the second function independent of the 
first one; i.e. to create a CO-PS VLAN layer network with VLAN IDs as 
tributary slot/link connection identifiers on VLAN Links (similar to VPI, 
VCI, label, timeslot) and VLAN connection functions [switches] that are 
able to perform VLAN ID translation/swapping. Each VLAN topological link 
would be able to carry 4k link connections (same number as on an ATM VP 
Link). With VLAN stacking it would be possible to create a hierarchy. With 
two [CO-PS] VLAN tags it would be similar to ATM (with its VC and VP 
levels). With an "infinite" number of [CO-PS] VLAN tags it would be 
similar to MPLS (LSP in tunnels in tunnels in tunnels in ..). 

This isn't "bridged ethernet" anymore; it is more "switched VLAN" or 
perhaps it could be called "switched ethernet". Nevertheless it would 
still use ethernet interfaces, now connected to "VLAN switches". Such 
Ethernet over [CO-PS] VLAN would be an alternative for Ethernet over MPLS 
and Ethernet over ATM. Any interest in such Ethernet CO-PS derivative? 

Regards,
Maarten

---------------------------------------------------------------------
Maarten Vissers
Network and Product Strategy - Optical Networks Division
Alcatel SEL AG 
Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The Netherlands
Mobile: +31 65 141 8140
Email:[email-masked]

<[email-masked]>
Sent by: [email-masked]
01-12-2003 16:08

        To:     <[email-masked]>
        cc:     <[email-masked]>, <[email-masked]>, <[email-masked]>, Maarten 
VISSERS/DE/ALCATEL@ALCATEL
        Subject:        RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

Stewart,

Stewart wrote 01 December 2003 13:37
<snipped>
> >>No PDH and SDH are different. These are port-based Ethernet 
> service; 
> >>whereas, I was talking about vlan-based services (e.g., each 
> >>VLAN is a VC) 
> >>and making analogy between VLAN-id in Ethernet and DLCI in FR 
> >>or VPI/VCI in 
> >>ATM.
> > 
> > NH=> I don't think this analogy is valid.  A VPI/VCI (ATM), 
> > DLCI (FR) or a 'label' (MPLS) are all examples of link-connection 
> > identifiers.  These entities have no network currency until/unless 
> > they are associated with some parent trail entity (no matter 
> > how that is created). 
> 
> Here you are talking about the inner label. The outer label
> would normally be an abbreviation for an IP address.
NH=> I think we need a better explantion as to what is actually going on 
here.  All co-ps/cs technologies work in essentially the same way.  If we 
take the largest subnetwork (G.805 sense) then the network access points 
are where it's addresses are located.  These are also intrinsically bound 
to trail termination functions.  The link-connections in co-ps/cs networks 
use labels that only have local (link) signficance.  When a trail is 
established between the network addressed access points than a series of 
concatenated link-connections and subnetworks (the smallest subnetwork 
being a node/switch in the technology of relevance) is created.....the 
link-connection IDs have no network currency before this, ie they sit in a 
pool waiting to be allocated (and are reuturned to the pool when the trail 
is torn-down).  So in all co-ps/cs technologies then 'yes' one could say a 
label points to some distant access point address.....and since the labels 
are a series of related/concatenated!
  links then this pointing to a distant destination address carries all 
the way to the access point at the trail source.

This is also why mp2p is a deprecated topology in the co-ps/cs 
modes.....though in the co-cs mode you simply can't physically create this 
violation, but you can force it in the co-ps mode.  Merging means we have 
lost transparency and integrity of the CI, ie we no longer uniquely know 
the source.  Which is why we are forced to run an extra p2p LSP above the 
mp2p construct to recover from the arch violation of this mode.  So the 
fact that the semantics of the label (ie inner vs outer) is now altered is 
simply a consequence of this arch violation.  Also note that IP belongs to 
the cnls mode and never has this problem....that is, the cnls mode always 
muxes and never merges....why?...because each traffic unit carries the 
full network DA/SA pair.....and that is indeed the signature of the cnls 
mode.
> 
> > A VLAN ID is not a link-connection 
> > identifier.  It is more like a 'name', in that it 
> > subdivides the total MAC address population into contained 
> > sub-spaces of MAC addresses (that belong to a given VLAN). 
> 
> Isn't it a virtual network identifier.
NH=> Yes, that was my point above saying it is a more like a 'name'....its 
not a link-connection ID in the same sense as VPI/VCI, DLCIs and MPLS 
labels are.

Stewart....I think we are wandering off topic now....so if this is to 
continue I suggest we change the title.

regards, Neil