[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet
Loa,
> yes - we can make a solution based on designated vlans
> "work", but if we do that we will have serious scaling issues
I think you might have misinterpreted what I was saying. I was talking
about using MPLS encap first and then have MPLS traffic over its
designated VLAN(s). All the GMPLS traffic can be carried over a single
VLAN or you can have more than one for load balancing purposes. And thus
there shouldn't be any scalability issues.
>
> i don't know if we are ready to start the discussion on
> solution, but we seems to do that anyway ;)
>
Apparently :-)
> there is a way for us to get a tpid from IEEE, we could
> specify the behavior of switches on that tpid
>
> my take that we shouldn't do that without involving ieee, but
> on the other it is normally quite easy to work with them
>
If interested one can come and discuss it during next 802.1 group (which
is the architecture group for IEEE bridges) meeting.
> but again we need to undestand requirements first
>
Completely agree.
-Ali
> /Loa
>
> Ali Sajassi (sajassi) wrote:
> > Dimitri,
> >
> > By "existing Ethernet switches", I mean Ethernet switches based on
> > current approved IEEE 802 .1Q/.1D standards and not the
> hypothetical
> > switches with TBD forwarding characteristics. Anyway, if
> the objective
> > is to use RSVP-TE with "existing Ethernet switches", you
> can do that
> > easily by designating a VLAN or (set of VLANs) for RSVP-TE
> traffic and
> > support both EoMPLS and native bridged traffic on a single trunk.
> > There is some overhead with such encapsulation but the
> benefit of it
> > is that it works now. If we want to do it through some other means
> > (such as MAC address translation), then the benefit of such
> approach
> > is not clear to me; however, the disadvantages are very clear
> > :-) Anyway, I'll look forward to more discussions during
> and after the
> > meeting next week.
> >
> > Cheers,
> > Ali
> >
> >
> --------------------------------------------------------------
> ----------
> > *From:* Dimitri.Papadimitriou@alcatel.be
> > [mailto:Dimitri.Papadimitriou@alcatel.be]
> > *Sent:* Tuesday, July 26, 2005 4:21 PM
> > *To:* Ali Sajassi (sajassi)
> > *Cc:* CHO, JAI HYUNG; Heiles Juergen; per@defero.se;
> ccamp@ops.ietf.org
> > *Subject:* RE: Frameformat in a l2cs gmpls rnvironment
> - Issues w/
> > GMPLS Ethernet
> >
> > ali
> >
> > to be clear here you are hanging on using the term "existing
> > Ethernet switches" while the document that has been at
> the source of
> > the discussion does not state "GMPLS must be deployable
> on existing
> > Ethernet switches" this may be the case but there are
> limitations
> > (and there are perfectly well understood, don't worry)
> beside this
> > you should also tell us what do you exactly mean with the term
> > "existing" - but this is a side issue -
> >
> > this said, this does NOT mean that a GMPLS Ethernet
> switch (either
> > existing or even "extended") would need to support a
> new Ethernet
> > 802.3 frame forwarding paradigm, the difference is
> subtle but has to
> > be underlined
> >
> > note: there is a slot of 20 minutes during the next
> CCAMP WG meeting
> > where this document and all related issues will be
> heavily discussed
> > ... so i welcome you to join the festivities ;-)
> >
> > thanks,
> >
> > - dimitri.
> >
> >
> >
> > *"Ali Sajassi \(sajassi\)" <sajassi@cisco.com>*
> > Sent by: owner-ccamp@ops.ietf.org
> > 07/25/2005 16:13 MST
> >
> > To: "CHO, JAI HYUNG" <jaihyung@etri.re.kr>, "Heiles Juergen"
> > <juergen.heiles@siemens.com>, <per@defero.se>
> > cc: <ccamp@ops.ietf.org>
> > bcc:
> > Subject: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/
> > GMPLS Ethernet
> >
> >
> > Jaihyung,
> >
> > It seems to me that your primary objective is to use
> the existing
> > Ethernet switches with new control plane (GMPLS) to
> setup TE paths for
> > different applications. And you mentioned three
> approaches for doing
> > this in your email. However, all three of them have
> issues and are not
> > viable. Lets go over them ...
> >
> > >
> > > In below mail, I discussed about three proposed approaches.
> > >
> > >
> > > 1. using VLAN tag as it is for L2 label encoding.
> >
> > As you know this approach has scalability issue and you
> are limited to
> > 4K services in the network and if you try to use the
> upcoming IEEE
> > 802.1ad standard to make VLANs, interface specific,
> then you will need
> > new switches and not existing Ethernet switches. Even
> if you use these
> > newer switches, you will still be limited to 4K
> services per interface
> > and it would defeat the objective of using existing switches.
> >
> > >
> > > 2. defining new protocol ID (TPID) and borrow VLAN
> tag format,
> > > ?or extended VLAN tag to implement label swapping.
> > >
> >
> > This approach requires new data plane functionality to
> be implemented
> > (which defeats the objective of using existing switches).
> >
> > > 3. use lower 3 bytes of MAC address for L2 label encoding.
> > >
> >
> > This approach has several issues:
> > 1) how does MAC addresses get distributed among the
> bridges ? How does
> > this distribution works during a link or node failure ?
> How does it
> > recover from a link or node failure ?
> >
> > 2) Will you assign a separate provider MAC for each
> customer MAC. If so,
> > then how do you address MAC scalability. If not, then
> how do you take
> > care of 1-to-N mapping between provider MAC address and
> customer MAC
> > addresses and how do you handle multipoint connections.
> >
> > 3) how do handle customer FCS retention when doing this
> MAC translation
> > stuff ??
> >
> > >
> > > 802.1Q bridge forwards Ethernet frames using two
> dataplane tables
> > > - MAC forwarding table and VLAN forwarding table.
> > > Bridge control protocols, such as GARP, GVRP, GMRP,
> > > manipulate one of the two dataplane entities.
> >
> > This is not correct. Bridges don't have different
> databases for MAC
> > forwarding and VLAN forwarding. They have filtering
> datebase(s) with
> > corresponding IDs (FIDs). VLAN IDs get mapped to FIDs
> based on operation
> > mode (IVL versus SVL). Then once a filtering database
> is identified,
> > then a MAC address lookup is performed for forwarding.
> Bridge control
> > protocols use a designated MAC addressed and based on these MAC
> > addressed, the bridge knows how to process the frame.
> >
> > >
> > > Similarly, option 1 and 3 are about which one of two
> > > dataplane entities
> > > GMPLS protocol should control on behalf of bridge
> control protocols.
> > > The two proposals do not intend to modify bridge behavior
> > > seriously, such as MAC learning, aging, filtering.
> > > Therefore, the approaches 1 and 3 are in the scope of CCAMP.
> >
> > If that's the intention, you may find out soon you get
> more than what
> > you asked for :-)
> >
> > >
> > > (% note however, I would regard implementing label swapping
> > > function is acceptable change considering the
> Internal Sublayer
> > > design of 802.1D bridge.)
> > >
> >
> > The only way of doing this is using VID translation
> table specified in
> > IEEE 802.1ad which requires new data-plane
> functionality and thus
> > existing bridges cannot be used !!
> >
> > Also if going the route of tag swapping, you may
> consider using IEEE
> > 802.1ah. As the editor of .1ah, I can go over the
> details when I get a
> > chance.
> >
> > >
> > > However, option 2 is about what TPID code we will
> > > choose to implement new switching function.
> > > The switch of this implementation should have new hardware
> > > design in addition to normal bride hardware.
> > > I think such proposal as option 2 is out of CCAMP scope.
> >
> > Yes.
> >
> > >
> > > Overall objective is improving scalability, traffic
> engineering (TE)
> > > characteristics of 802.1 bridge that it can be
> reliable, manageable
> > > enough to replace some core routers.
> >
> > Easier said than done :-)
> >
> > > The switching technique you mentioned above, such as
> > > Ethernet over MPLS as defined by PWE3 and L2VPN,
> > > are all actually router based technology, however this
> > > work is based on simple bridge architecture.
> > > Cost-effectiveness is the key differentiator.
> > >
> >
> > The devils are in the details and once you worked out
> the details, you
> > will see the issues.
> >
> > >
> > > In access or enterprise network, capability of
> providing end-to-end
> > > L2-LSP will enable service providers policing,
> measuring, charging
> > > application flows using Ethernet based network. This
> will eventually
> > > improve income structure and introduce new session
> based commercial
> > > service. I have been discussing this aspect in mail thread of
> > > title 'End-to-end L2-LSP'. Please read the mail
> thread and comment
> > > on the discussion.
> > >
> > >
> > > >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?
> > >
> > >
> > > TRILL employs new encapsulation layer outside of
> Ethernet frames.
> > > However in my proposal of option-3, I simply use the
> Ethernet header
> > > to encode GMPLS label.
> > >
> > > The overall format of rbridge is
> > > [Ethernet][r-tag][Ethernet][ data..]
> > > It is not LSP based technology but a connectionless
> routing bridge.
> > > TTL count is very important in rbridge because
> frames are routed
> > > hop-by-hop and it may loop.
> > >
> > > Whereas in option-3 above, Ethernet frames that have certain
> > > OUI prefix in MAC address are forwarded via a path that
> > > GMPLS protocol has configured on MAC forwarding table.
> > >
> >
> > How does the redundancy work in here. Are you using
> bridge protocol in
> > conjunction with GMPLS protocol. If you do, then there
> are bunch of
> > issues. If you don't, then what is it used and how does
> it interact with
> > bridging protocols ??
> >
> > -Ali
> >
> >
> > >
> > > Thanks
> > >
> > > Jaihyung
> > >
> > >
> > >
> > > -----?? ???-----
> > > ?? ??: "Heiles Juergen" <juergen.heiles@siemens.com>
> > > ?? ??: 2005-07-25 ?? 6:44:34
> > > ?? ??: "CHO, JAI HYUNG" <jaihyung@etri.re.kr>, "Heiles
> > > Juergen" <juergen.heiles@siemens.com>, "per@defero.se"
> > > <per@defero.se>
> > > ??: "ccamp@ops.ietf.org" <ccamp@ops.ietf.org>
> > > ??: 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
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
>
>
> --
> 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
>