[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet
Hi, Ali
sorry for late in this response.
a bit busy at preparing trip to Paris.
see in-line
[snip]
>>> >
>>> >> 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 ?
>>
>> Ali,
>> The questions are really implementation dependent.
>> Can we defer this discussion after Paris meeting?
>> However, I see the solution will not be so different than
>> what RSVP-TE has been done for other transport network.
>
>These questions are not implementation dependent. IEEE bridges have a
>well established procedures for handling link and node failures based on
>RSTP/MSTP and "independent" interaction between these procedures and
>RSVP-TE is questionable at best. If you think this is not the case, then
>I encourage you to specify how this interaction works.
Honestly, it's not clear for me what is the point you trying to make.
RSVP-TE works on well-established IP routing protocols,
and MPLS/GMPLS define LSP restoration mechanism well.
I believe you understand well how RSVP-TE distributes
generic label between nodes in the event of failure.
I'm a bit surprised a cisco guy saying such doubt on RSVP-TE.
I still feel this is not necessary talk at this stage.
Clear answer can be given after we settle down solution.
>>
>> >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.
>>
>>
>> I think you are asking the issue of L2 label stacking or LSP
>> aggregation, or perhaps some VPN application similar to 802.1ad.
>> There are some opinions on whether label stacking is
>> necessary in L2SC domain. This is actually the question
>> Adrian keep asking us.
>
>Since you are using provider MAC address as a label, then by label
>stacking, I presume you mean encapsulating customers MAC addresses
>inside the provider MAC.
That'll depend on service function configured in ingress node.
1. If ingress is PSC, (i.e. L3/L4 switching or MPLS), provider MAC header
?will encapsulate user IP packet or MPLS packet
2. If ingress provides L2 VPN service, provider MAC will encapsulate
?user MAC, thus it'll be MAC-in-MAC as you said.
3. If ingress provides end-to-end L2-LSP connection, it'll simply change
?user MAC address to GMPLS prefixed L2 label at ingress.
this case only be valid in enterprise/access network.
I told it before in reply to Juergen.
please read past mails carefully.
Scalability performance must be discussed respectively
at the three cases.
>If you want to go to that extend, then why not
>just simply use IEEE 802.1ah that provide both stacking of MAC addresses
>as well as it provides you with a 20-bit tag for service instance
>identification.
No, because of at least four reasons,
1. assuming new definition of dataplane is not in CCAMP scope,
as you also agreed.
2. such machine will only be compatible with the same kind.
?backward compatibility to 802.1D/Q bridge is important goal to us,
?so that the GMPLS implemented switch may inter-mix with
?legacy bridges.
3. we are not intending to develop it just for metro-LAN service.
as I told in above, several different service application,
such as campus Internet service, MPLS-LSP backbone, etc.
can also be considered.
4. we can achieve far more flexible, compatible, scalable solution
than your proposal if we combine L2 label with MPLS shim labels.
?besides, if the format you propose is something like
?[MAC][20bit-tag][ IP ][ .. data ...]
?than is it in fact a MPLS label switching?
?if it is your proposal, why not just extend MPLS specs a bit,
?rather than creating new one?
>> I personally think that we can achieve LSP aggregation with
>> the aid of MPLS shim label, however I think this is too
>> premature discussion.
>> All I can say at the moment is, lower 3 octet of MAC address
>> gives us 16M size of label space and this is enough to
>> implement link-local, site-local or even some domain-local LSPs.
>> Between the L2-LSP boundary, it needs further discussion.
>>
>It is one thing to have the address space, it is another thing to have
>proper management and control protocols to manage that space. The big
>question is what type of control and management protocols you intend to
>use for that space and how it interacts with the existing IEEE control
>and management protocols. Also, if it is one-to-one mapping, then we are
>back to square one regarding MAC address scalability.
control ? ==> of course, GMPLS.
management? ==> not in my interest.
it seems you are talking about address management mechanism.
Precedence of such solution is far later.
>> >
>> >3) how do handle customer FCS retention when doing this MAC
>> translation
>> >stuff ??
>>
>> I haven't seen any application that requires retention of
>> original FCS image.
>> 802.1D specification recommends recalculation of FCS when
>> there is any change in MAC. I see no problem if FCS is
>> recalculated at the label swapping switch.
>
>Please refer to all the discussions on the PWE3 mailing list regarding
>FCS retention. There are certain applications that require it and that's
>why there is a draft for it.
ok, thanks, I found there's some people worrying about this,
however, such worry is not in the scope of my idea.
It is even not clear if there's requirement exist for
PWE service using L2-LSP.
[snip]
>>
>> If we define the scope of L2 label as site-local or
>> domain-local, we don't need such label swapping operation.
>> However, if we want link-local label, and find out that it is
>> very useful
>> (* actually I do think it'll be very useful *), I think we
>> need to consult such modification with IEEE.
>> Technically speaking, I don't think replacing the label value
>> after normal MAC lookup will serious change hardware architecture.
>> Also, it doesn't break conformance rule.
>> Did any 802.1 spec. say that input MAC must be identical to
>> output MAC?
>
>There is no MAC address swapping or translation in .1D, .1Q, or its
>future standards. If there is MAC address translation, then you can run
>into quite a few unwanted side affects.
so, which conformance rule does it break in 802.1D/Q spec.
if we translate MAC address ?
In fact, some bridge vender sells MAC translating switch
for security purpose because it can hide internal MAC information.
It doesn't cause any side-effect.
You need to be specific what side-effect it may cause.
[snip]
>> >
>> >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.
>>
>>
>> Yes I do.
>> I intend GMPLS implemented switches being deployed in
>> operating network
>> as normal Ethernet switch that perform bridge protocols.
>> When they detect (or snoop) RSVP-TE message, they establish L2-LSP
>> and selectively forward those GMPLS prefixed frames via the L2-LSP.
>> The message path that RSVP-TE is exchanged, thus L2-LSPs are
>> established, does not necessarily be identical to spanning tree path
>> because L2-LSPs can be established via shortest path.
>> I welcome further discussion on this issue, but I hope to continue it
>> after Paris meeting, if you may.
>
>If RSVP-TE traffic uses link-state based protocols and bridged traffic
>uses distance-based protocols (e.g., RSTP) and these traffic operate
>independently from each other and both types of traffic come through the
>same port, then how does a standard IEEE bridge know how to discern
>these packets and which packets to take action on ? - e.g., what IEEE
>procedures do you recommend to be used ?? If you are talking about
>different physical ports, then you are talking about different
>independent networks with different set of links and topology for each
>which is not the intent here.
Normal MAC lookup is sufficient.
MAC entries for normal frames are learned as bridge relay function.
The frames are forwarded via active ports as usual.
MAC entries for GMPLS frames are configured by GMPLS protocols.
GMPLS frames may be forwarded via active ports as well as
some standby ports that are not used by spanning tree.
Of course in this case, GMPLS control messages need to be
forwarded via standby ports.
Thanks
Jaihyung
-----?? ???-----
?? ??: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
?? ??: 2005-07-27 ?? 12:00:53
?? ??: "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 - Issues w/ GMPLS Ethernet
Jaihyung,
Please refer to my comments inline ...
[snip]
> >
> >> 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 ?
> >
>
>
> Ali,
> The questions are really implementation dependent.
> Can we defer this discussion after Paris meeting?
> However, I see the solution will not be so different than
> what RSVP-TE has been done for other transport network.
>
These questions are not implementation dependent. IEEE bridges have a
well established procedures for handling link and node failures based on
RSTP/MSTP and "independent" interaction between these procedures and
RSVP-TE is questionable at best. If you think this is not the case, then
I encourage you to specify how this interaction works.
>
> >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.
>
>
> I think you are asking the issue of L2 label stacking or LSP
> aggregation, or perhaps some VPN application similar to 802.1ad.
> There are some opinions on whether label stacking is
> necessary in L2SC domain. This is actually the question
> Adrian keep asking us.
Since you are using provider MAC address as a label, then by label
stacking, I presume you mean encapsulating customers MAC addresses
inside the provider MAC. If you want to go to that extend, then why not
just simply use IEEE 802.1ah that provide both stacking of MAC addresses
as well as it provides you with a 20-bit tag for service instance
identification.
> I personally think that we can achieve LSP aggregation with
> the aid of MPLS shim label, however I think this is too
> premature discussion.
> All I can say at the moment is, lower 3 octet of MAC address
> gives us 16M size of label space and this is enough to
> implement link-local, site-local or even some domain-local LSPs.
> Between the L2-LSP boundary, it needs further discussion.
>
It is one thing to have the address space, it is another thing to have
proper management and control protocols to manage that space. The big
question is what type of control and management protocols you intend to
use for that space and how it interacts with the existing IEEE control
and management protocols. Also, if it is one-to-one mapping, then we are
back to square one regarding MAC address scalability.
>
> >
> >3) how do handle customer FCS retention when doing this MAC
> translation
> >stuff ??
> >
>
>
> I haven't seen any application that requires retention of
> original FCS image.
> 802.1D specification recommends recalculation of FCS when
> there is any change in MAC. I see no problem if FCS is
> recalculated at the label swapping switch.
Please refer to all the discussions on the PWE3 mailing list regarding
FCS retention. There are certain applications that require it and that's
why there is a draft for it.
>
>
> >> 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.
>
>
> oh, come on .
> I explained it in conceptual level and you re-described it in
> implementation level. The contextual meaning is same.
> I believe you don't deny the existence of two types of
> filtering databases, for MAC and VID, and the control of GARP
> over these databases.
> This is unnecessary argument, I think.
>
No, I didn't describe the implementation but instead I described it as
specified in .1D and .1Q. However, I see what you were trying to say and
I think it was just a poor choice of words.
[snip]
>
> If we define the scope of L2 label as site-local or
> domain-local, we don't need such label swapping operation.
> However, if we want link-local label, and find out that it is
> very useful
> (* actually I do think it'll be very useful *), I think we
> need to consult such modification with IEEE.
> Technically speaking, I don't think replacing the label value
> after normal MAC lookup will serious change hardware architecture.
> Also, it doesn't break conformance rule.
> Did any 802.1 spec. say that input MAC must be identical to
> output MAC?
There is no MAC address swapping or translation in .1D, .1Q, or its
future standards. If there is MAC address translation, then you can run
into quite a few unwanted side affects.
[snip]
>
>
> [snip]
> >
> >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.
>
>
> Yes I do.
> I intend GMPLS implemented switches being deployed in
> operating network
> as normal Ethernet switch that perform bridge protocols.
> When they detect (or snoop) RSVP-TE message, they establish L2-LSP
> and selectively forward those GMPLS prefixed frames via the L2-LSP.
> The message path that RSVP-TE is exchanged, thus L2-LSPs are
> established, does not necessarily be identical to spanning tree path
> because L2-LSPs can be established via shortest path.
> I welcome further discussion on this issue, but I hope to continue it
> after Paris meeting, if you may.
If RSVP-TE traffic uses link-state based protocols and bridged traffic
uses distance-based protocols (e.g., RSTP) and these traffic operate
independently from each other and both types of traffic come through the
same port, then how does a standard IEEE bridge know how to discern
these packets and which packets to take action on ? - e.g., what IEEE
procedures do you recommend to be used ?? If you are talking about
different physical ports, then you are talking about different
independent networks with different set of links and topology for each
which is not the intent here.
Cheers,
Ali
>
>
> Thanks
>
> Jaihyung
>
>
> -----?? ???-----
> ?? ??: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
> ?? ??: 2005-07-26 ?? 8:13:56
> ?? ??: "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 - 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
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
>
>