[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Generalized Signaling - LSP Encoding Type expansion



Title: RE: Generalized Signaling - LSP Encoding Type expansion

Dimitri,

One thing to bear in mind with the Bandwidth Encoding values is that they are nothing more than floating point numbers, so I do not see any need to necessarily update them for FiberChannel necessarily - hopefully people are capable of mapping bit rates to floating point without having the mapping explicitly stated in the document. So I infer from this that a FiberChannel LSP Encoding Type is acceptable to all?

Ewart

> -----Original Message-----
> From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be]
> Sent: Monday, October 22, 2001 6:33 PM
> To: Tempest, Ewart [SKY:XW44:EXCH]
> Cc: lberger@movaz.com; ccamp@ops.ietf.org
> Subject: Re: Generalized Signaling - LSP Encoding Type expansion
>
>
> Hi Ewart,
>
> As we speak as individual (or groups of individuals) here i would
> rephrase your first sentence as "i think support of ..." the
> importance of the support of FC doesn't depend on your private
> affiliation. Also if FC is included we would have to update the
> Bandwidth values as well.
>
> Concerning your question i think you have responded by yourself to
> it; please check section 3.1.2 of GMPLS-SIG and 2.1.2 of Generalized
> RSVP-TE (a mention could be considered).
>
> Regards,
> Dimitri.
>
> > Ewart Tempest wrote:
> >
> > Dimitri,
> >
> > Yes, Nortel requires support for FiberChannel. There should be no
> > issues with this - it is merely a different physical layer.
> If not all
> > LSRs within a network support it, then fine, it will not be
> capable of
> > setting up an LSP with this encoding type (unless a technology
> > transformation is applied by an LSR, typically the ingress LSR or
> > delegate device, to effectively tunnel through a network
> that does not
> > support this LSP Encoding Type).
> >
> > As far as GE goes, a GE port is not interoperable with a 100BaseT
> > Ethernet port is not interoperable with a 10BaseT Ethernet port ...
> > etc. So to have these all lumped in one generic Ethernet 802.3
> > umbrella may or may not make sense depending on the
> original intent of
> > the LSP Encoding Type (not clear from the document). If I were the
> > destination of an LSP, I would want to make sure that the LSP
> > requested was being terminated on an appropriately capable
> port given
> > the LSP Encoding Type and G-PID supplied. If all I am given is
> > Ethernet 802.3, how do I know whether this refers to GE, 10BaseT or
> > 100BaseT (or should this be inferred from the bandwidth specified in
> > the SENDER_TSPEC object)? In fact, one could argue that the
> egress LSR
> > might need to know this information too, since it is the one that
> > selects the port/link to the LSP destination. If the SENDER_TSPEC is
> > to be used to distinguish between the various Ethernet
> flavours, then
> > a mention of this in section 3.1.1 would be helpful, and I
> would then
> > agree with you that a separate LSP Encoding Type for GE is not
> > required.
> >
> > Ewart
> >
> > > -----Original Message-----
> > > From: Dimitri Papadimitriou
> > [mailto:dimitri.papadimitriou@alcatel.be]
> > > Sent: Monday, October 22, 2001 2:47 PM
> > > To: Tempest, Ewart [SKY:XW44:EXCH]
> > > Cc: lberger@movaz.com; ccamp@ops.ietf.org
> > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion
> > >
> > >
> > > Hi Ewart,
> > >
> > > If you take a look on the IEEE Standards you will see
> > > that GE is referred to as
> > > - 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab
> > > - 802.3ae for 10Gbps (see below [2])
> > >
> > > So my question is what do you have in mind ? to separate
> > > these values ?
> > >
> > > Thanks,
> > > Dimitri.
> > >
> > > PS: for FiberChannel sorry i am not an expert but is someone
> > >     targeting to use GMPLS for FiberChannel LSP ?
> > >
> > > -------
> > >
> > > [1] From - http://standards.ieee.org
> > >
> > > Project scope: Define Carrier Sense Multiple Access with Collision
> > > Detection (CSMA/CD) Media Access Control (MAC) parameters and
> > minimal
> > > augmentation of its operation, physical layer
> > > characteristics, repeater
> > > functions and management parameters for transfer of 802.3 and
> > > Ethernet
> > > format frames at 1,000 Mb/s.
> > >
> > > Project purpose: The purpose of this project is to extend
> the 802.3
> > > protocol to an operating speed of 1,000 Mb/s in order to provide a
> > > significant increase in bandwidth while maintaining maximum
> > > compatibility
> > > with the installed base of CSMA/CD nodes, previous investment in
> > > research
> > > and development, and principles of network operation and
> management.
> >
> > >
> > > [2] From - http://standards.ieee.org
> > >
> > > Project scope: Define 802.3 Media Access Control (MAC) parameters
> > and
> > > minimal augmentation of its operation, physical layer
> > characteristics
> > > and management parameters for transfer of LLC and Ethernet format
> > > frames at 10 Gb/s using full duplex operation as defined in the
> > 802.3
> > > standard. In addition to the traditional LAN space, add
> > > parameters and
> > > mechanisms that enable deployment of Ethernet over the Wide
> > > Area Network
> > > operating at a data rate compatible with OC-192c and SDH VC-4-64c
> > > payload
> > > rate.
> > >
> > > Project purpose: The purpose of this project is to extend
> the 802.3
> > > protocol to an operating speed of 10 Gb/s and to expand
> the Ethernet
> >
> > > application space to include Wide Area Network links in order
> > > to provide
> > > a significant increase in bandwidth while maintaining maximum
> > > compatibility
> > > with the installed base of 802.3 interfaces, previous
> investment in
> > > research
> > > and development, and principles of network operation and
> management.
> >
> > >
> > > -------
> > >
> > > > Ewart Tempest wrote:
> > > >
> > > > Lou,
> > > >
> > > > Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06
> > can
> > > > you please add additonal LSP Encoding Types for GE and
> > FiberChannel.
> > > > GE is not really covered by the existing Ethernet
> related encoding
> >
> > > > types, and FiberChannel is not covered at all. Thanks.
> > > >
> > > > Ewart
> > >
>