[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Frameformat in a l2cs gmpls rnvironment.
I fully agree with Juergen's comments. The key question that's still not clear in my mind here is, what is the real motivation for this work? Is it to simply support dynamic VLAN provisioning for Ethernet based on shortest/TE paths using GMPLS instead of using OSS? Or is it to develop an alternative CO-PS solution (to say ATM or MPLS) using the Ethernet frame structure, regardless of whether or not the Ethernet forwarding behaviour (and hardware) needs to be modified?
If the scope of the proposal does not prevent the Ethernet forwarding behaviour being modified resulting in "the switching hardware, the filter and relay, etc. are totally different new dataplane switch", then this seems to be contradictory to an earlier comment from Dimitri that said "the definition of any data plane behaviour is outside of the scope of the DT charter and the document it produced". This also raises questions regarding the role of the IEEE and what the applications/goals/benefits of the new Ethernet forwarding behaviour will be.
If on the other hand the goal is to use the Ethernet data plane as it stands today based on MAC address learning/switching, but to replace manual/OSS VLAN provisioning with a GMPLS CP, it seems to me that there is a fundamental difference between this proposal and all other GMPLS solutions. In all the GMPLS solutions I'm aware of, the label signalled via GMPLS (e.g. ATM VPI/VCI, WDM wavelength, etc.) is also used for forwarding in the data plane. However in this case, data plane forwarding is not based on a label (VLAN ID) but on an address, i.e. the destination MAC address. Instead, the label is used to restrict the broadcast domain (e.g. to a P2P path), which (following MAC flooding/learning) results in the packets belonging to a particular VLAN following the same path. Although the result is effectively the same, the fact that forwarding is not based on the label signalled using GMPLS may cause complications. For example, when a failure occurs, in addition to re-routing or switching over to backup paths, the MAC databases/tables of all effected nodes must be purged on a per VLAN basis.
Looking at section 4, I agree that one obvious benefit (as mentioned in section 4) would be the ability to dynamically calculate loop-free shortest/TE paths, which would allow operators to switch off spanning tree. However as Juergen points out, this is one of the goals for the TRILL WG (although the solution proposed is different), so I would like to understand what the common/opposing goals are. Another example from section 4 is the point about improving scalability by introducing IP addressing with GMPLS rather relying on MAC addresses, which are not hierarchical. This point is only valid if the control plane is being used to carry Ethernet addresses. So, this might be a valid point when comparing the TRILL solution to the GMPLS solution for example, but is not valid when comparing a standard 802.1 Ethernet network to a GMPLS L2-LSP network. The reason being that both solutions are still based on data plane learning using MAC addresses and are therefore both subject to the same data plane scaling issues, i.e. for the solution to scale to large numbers of Ethernet customers, MAC-in-MAC encapsulation will be required. Therefore, what will the benefits of using L2-LSPs with MAC-in-MAC be compared to encapsulating Ethernet in MPLS PWs?
Regards,
Richard
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of Heiles Juergen
> Sent: 25 July 2005 10:45
> To: CHO, JAI HYUNG; Heiles Juergen; per@defero.se
> Cc: ccamp@ops.ietf.org
> Subject: RE: Frameformat in a l2cs gmpls rnvironment.
>
>
> Dear Jaihyung,
>
> you mention several options that could be used as a label.
> Most of them have strong impacts on the data plane and
> introduce new layer networks. Is this in the scope of CCAMP?
> What is the goal, to introduce a control plane for a existing
> L2 technology or introduce a new L2 technology? What would be
> the benefit of such a new L2 co switching technology compared
> to Ethernet over MPLS as defined by PWE3 and L2VPN?
> You mentioned to use the MAC address or part of it as a
> label. The TRILL working group is defining shortest path
> routing for Ethernet. How would this fit together?
>
>
> Regards
>
> Juergen
>
>
>
>
>
> > -----Original Message-----
> > From: CHO, JAI HYUNG [mailto:jaihyung@etri.re.kr]
> > Sent: Saturday, July 23, 2005 6:19 AM
> > To: Heiles Juergen; per@defero.se
> > Cc: ccamp@ops.ietf.org
> > Subject: RE: Frameformat in a l2cs gmpls rnvironment.
> >
> >
> > Dear Juergen, Par and all,
> >
> > The proposed framework of L2SC was not intended to suggest
> > any specific solution. It is still an open question.
> > As Adrian noted, it only aims to present requirements
> > as in scenarios that may drive people toward next step in many
> > viable solutions.
> >
> > In fact, there are other options we may also consider for L2
> > label encoding.
> > IEEE 802.1 Ethernet bridges forward frames based on 48bits of
> > MAC address,
> > and additionally using VLAN tag.
> >
> > When the purpose of GMPLS control over Ethernet is not to
> > create new dataplane
> > but to utilize IEEE 802.1 bridge architecture, we may
> consider using
> > one of the two forwarding methods, MAC forwarding or VLAN
> forwarding.
> > (and perhaps any other combination of fields in MAC, but I'll
> > not discuss it)
> >
> > Use of VLAN ID for label encoding may automate VLAN configuration
> > using IP protocols. However, GMPLS protocol cannot use the
> > field exclusively
> > because public/private operators already use VLAN for various
> > purpose.
> > There is a potential conflict with existing use of VLAN and
> > GMPLS use of VLAN label.
> > Furthermore, scalability of VLAN ID has been frequently noted
> > as weakness
> > because the size of VLAN ID is at most 4096 (12bit).
> >
> > The scalability may be improved if the scope of VLAN label is
> > confined to
> > link-local, and some additional swapping function of VLAN ID
> > is introduced in
> > Internal Sublayer [802.1D] of GMPLS implemented switch.
> > However, this will only be effective when the configuration
> > of network
> > is mesh structure that multiple LSP paths exist. If the
> > configuration of network
> > is star or tree shape, as normal configuration of access network,
> > LSPs concentrate in root node and total number of
> > LSPs that the network can hold still be limited by available
> > label space
> > at a few root links.
> >
> > For these reasons, I do not think any form of VLAN ID label is
> > an appropriate choice for layer-2 label encoding.
> >
> > There are some other proposals assuming new assignment of Ethernet
> > Length/Type value (e.g. new TPID in VLAN tag) and re-definition of
> > information fields placed between 802.3 MAC header and IP packet.
> > In this case, only the format of VLAN tag or extended VLAN tag
> > is borrowed, however, inside the switching hardware, the
> > filter and relay,
> > etc. are totally different new dataplane switch.
> >
> > I do not see such approach is a GMPLS implementation for Ethernet
> > because the core switching technique is not 802.1 Ethernet
> > bridge at all.
> >
> > The other option we may consider is using MAC address filed
> as below.
> >
> >
> > +-------+-------+-------+-------+-------+-------+
> > | 1byte | 2byte | 3byte | 4byte | 5byte | 6byte |
> > +-------+-------+-------+-------+-------+-------+
> > +-----------------------+-----------------------+
> > | OUI Prefix (=GMPLS) | DA-label (24bit) |
> > +-----------------------+-----------------------+
> > | OUI Prefix (=GMPLS) | SA-label (24bit) |
> > +---------------+-------+-----------------------+
> > | Length/Type |
> > +---------------+
> >
> >
> > IEEE is designated by the ISO Council to act as the
> > registration authority
> > for the higher three-octet of OUI number in the MAC address
> > to be used by manufacturer. Ethernet manufacturer may generate
> > global unique MAC address using the OUI prefix and address block of
> > lower three-octet (24bit). Taking advantage of the
> addressing scheme,
> > GMPLS may use the lower three-octet exclusively if a unique
> > OUI number
> > is reserved for the protocol. With this labeling scheme, GMPLS will
> > control MAC forwarding entry, not VLAN table.
> >
> > All Ethernet frames controlled by GMPLS will have identical
> > OUI number
> > that they can easily be distinguished from other Ethernet frames.
> > In principle, the label lookup hardware is identical to MAC lookup
> > hardware in this labeling scheme. Therefore GMPLS implemented
> > switch may still function as normal Ethernet bridge to the frames
> > that OUI number is not GMPLS. This also facilitates GMPLS
> implemented
> > switches being deployed in operating Ethernet with minimum
> > service disruption.
> >
> > Note also that above proposed label encoding method is transparent
> > to the use of Ethernet Length/Type field. End-user device may use
> > the Length/Type field as defined in IEEE 802.3 protocol.
> > It also allows network operators configure VLAN for their own
> > purpose.
> > When IEEE 802.1p is used in conjunction with L2-LSP, the priority
> > field of VLAN tag can also be used for imposing consistent TE
> > policy in
> > legacy switches and GMPLS switches.
> >
> > Any way, my conclusion is, there are other options we may consider,
> > and this issue is still open to discuss.
> >
> > Thanks,
> >
> > Sincerely,
> >
> > Jaihyung
> >
> >
> >
> >
> >
> > -----?? ???-----
> > ?? ??: "Heiles Juergen" <juergen.heiles@siemens.com>
> > ?? ??: 2005-07-22 ?? 10:23:43
> > ?? ??: "Loa Andersson" <loa@pi.se>, "richard.spencer@bt.com"
> > <richard.spencer@bt.com>
> > ??: "per@defero.se" <per@defero.se>, "ccamp@ops.ietf.org"
> > <ccamp@ops.ietf.org>
> > ??: RE: Frameformat in a l2cs gmpls rnvironment.
> >
> >
> >
> >
> >
> >
> > Loa,
> >
> > I interpret the ID as a proposal to use GMPLS for VLAN setup.
> > So GMPLS and VLAN to not compete. The VLAN is at the data
> > plane and GMPLS at the control plane. The question is how and
> > should different control plane techniques like GMPLS and
> > (GVRP and STB) work together?
> >
> > Regards
> >
> > Juergen
> >
> >
> > > -----Original Message-----
> > > From: owner-ccamp@ops.ietf.org
> > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Loa Andersson
> > > Sent: Friday, July 22, 2005 2:53 PM
> > > To: richard.spencer@bt.com
> > > Cc: per@defero.se; ccamp@ops.ietf.org
> > > Subject: Re: Frameformat in a l2cs gmpls rnvironment.
> > >
> > > Richard,
> > >
> > > I agree to most of this. Since we have doubts about the viability
> > > of taking GMPLS all the way to end-user or enterprise I think it
> > > would be good, from a wg perspective, if we agreed to solve the
> > > core network problems first.
> > >
> > > Do you have any comment on the requirement to run both VLANs and
> > > GMPLS on the same switch?
> > >
> > > /Loa
> > >
> > > richard.spencer@bt.com wrote:
> > > > Regardless of whether or not a switch is directly connected
> > > > to hosts, it must be able to forward packets using the
> > > connectionless
> > > > Ethernet data plane. This is due to the fundamental
> > > requirement that
> > > > for GMPLS switches to be able to exchange control
> > information with
> > > > each other, a data plane for control traffic must be present.
> > > > This is akin to using the IP data plane for MPLS
> > signalling in an
> > > > IP/MPLS network. An alternative would be to use a static
> > reserved
> > > > L2-LSP for control traffic in the same way that reserved
> > VPI/VCIs
> > > > are used for PNNI signalling in ATM.
> > > >
> > > > Regarding connecting hosts to GMPLS switches, I
> personally don't
> > > > think extending L2-LSPs into the enterprise/home network is
> > > > commercially viable. However, if you do want to use
> > GMPLS switches
> > > > in the home/enterprise network and for some reason
> don't want to
> > > > extend L2-LSPs down to the host then you will not be
> performing
> > > > normal Ethernet Mac address switching anyway. Instead you will
> > > > need some kind of policy on the switch that maps
> connectionless
> > > > Ethernet packets (e.g. based on MAC src/dest, 802.1p,
> VLAN) to a
> > > > L2-LSP. This is because multiple L2-LSPs to the same
> destination
> > > > (e.g. a gateway router) may exist for different services/flows
> > > > (e.g. video download, VoIP call, etc.).
> > > >
> > > > Regards,
> > > > Richard
> > > >
> > > >
> > > >>-----Original Message-----
> > > >>From: owner-ccamp@ops.ietf.org
> > [mailto:owner-ccamp@ops.ietf.org]On
> > > >>Behalf Of Par Mattsson
> > > >>Sent: 22 July 2005 11:42
> > > >>To: Loa Andersson
> > > >>Cc: ccamp@ops.ietf.org
> > > >>Subject: Re: Frameformat in a l2cs gmpls rnvironment.
> > > >>
> > > >>
> > > >>
> > > >>>Per and Dimitri,
> > > >>>
> > > >>>I would like to come down stronger than that, for me it is
> > > >>>a very strong requirement that the same switch can handle
> > > >>>both VLANs and GMPLs trafic correctly. I can't dsee how that
> > > >>>could be done if using the VLAN tpid to indicate GMPLS
> > > >>>traffic.
> > > >>
> > > >>If you ever want that same switch to handle traffic for a
> > directly
> > > >>connected host (not to uncommen) you would want that to
> > use normal
> > > >>ethernet macaddress switching. So of course you do not want
> > > to have to
> > > >>choose between vlan and gmpls, you would want both at the
> > same time.
> > > >>
> > > >>/per
> > > >>
> > > >>
> > > >>
> > > >>>/Loa
> > > >>>
> > > >>>Par Mattsson wrote:
> > > >>>
> > > >>>>>hi par, one of the possibilities that has been considered
> > > >>
> > > >>to cope with
> > > >>
> > > >>>>>this requirement is to use a dedicated TPID for the
> > > >>
> > > >>Ethernet labeled
> > > >>
> > > >>>>>frames; this would allow differentiated processing with
> > > non-labeled
> > > >>>>>framesthanks.
> > > >>>>
> > > >>>>
> > > >>>>That seems to make more sence. If that frame is to be
> > sized like a
> > > >>>>802.1q
> > > >>>>frame. There is not that much space left to a label. Or is
> > > >>
> > > >>the demand to
> > > >>
> > > >>>>use jumboframes ?
> > > >>>>Has there been any discussion on labelstacking, and
> > > mainly where to
> > > >>>>place
> > > >>>>the information?
> > > >>>>
> > > >>>>Regards.
> > > >>>>Per
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>>--
> > > >>>Loa Andersson
> > > >>>
> > > >>>Principal Networking Architect
> > > >>>Acreo AB phone: +46 8 632 77 14
> > > >>>Isafjordsgatan 22 mobile: +46 739 81 21 64
> > > >>>Kista, Sweden email:
> > loa.andersson@acreo.se
> > > >>> loa@pi.se
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >
> > >
> > >
> > > --
> > > Loa Andersson
> > >
> > > Principal Networking Architect
> > > Acreo AB phone: +46 8 632 77 14
> > > Isafjordsgatan 22 mobile: +46 739 81 21 64
> > > Kista, Sweden email: loa.andersson@acreo.se
> > > loa@pi.se
> > >
> >
> >
> >
> >
>
>