[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
> >
>
>
>
>