[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Generalized Signaling - LSP Encoding Type expansion
I think it's the case that if we'e dealing with end-end services across a
GMPLS core, the types of end-end services that could be supported is fairly
open without having to upgrade the GMPLS core, and without having to require
every vendor implementing GMPLS to support every conceivable type of end-end
service. I.e., you could deploy a GMPLS network with core switches from
vendor 1, SONET/SDH grooming service devices from vendor 2, IP router
service devicess from vendor 3, ATM service devices from vendor 3,
transparent LAN service devices from vendor 4, private line service devices
from vendor 5, etc
-----Original Message-----
From: Yakov Rekhter [mailto:yakov@juniper.net]
Sent: Tuesday, October 23, 2001 8:17 AM
To: Lazer, Monica A, NNAD
Cc: 'shehzad.mirza@bt.com'; ccamp@ops.ietf.org
Subject: Re: Generalized Signaling - LSP Encoding Type expansion
Monica,
> All,
> I am in full agreement with Shehzad. From a carrier's perspective, the
value
> of the control plane is in taking over specific functions which currently
> reside in OSSs outside of the network itself. Having only some
applications,
> but not others of the given function move into the network greatly
> diminishes the value of having that function supported in the control
plane.
> To be more specific, if out of n services supported by the transport
> network, the control plane supports automated provisioning of 1/2n
services
> and the other 1/2n need support in the OSS, we still need to do the OSS
work
> for the given transport technology. So from a cost perspective, now we
have
> to ask ourselves whether we should pay for the provisioning function
twice.
While what you said makes sense from a given carrier's perspective,
we need to take a broader view, as producing a "perfect solution"
that meets *all* the requirements of *all* the carriers is an
explicit non-goal of GMPLS. With this in mind, if the 1/2n services
that aren't supported by the control plane are the services that
are required by 90% of the carriers market, then indeed this is a
problem. On the other hand, if these 1/2n services that aren't
supported are the services required by only 10% of the carriers
market, then this is quite acceptable. Understandably, the carriers
who would fall into this 10% category could be quite unhappy about,
and could even be quite vocal in expressing their dissatisfaction...
Yakov.
> Regards,
>
> Monica A. Lazer
> Advanced Transport Technology and Architecture Planning
>
> 908 234 8462
> mlazer@att.com
>
>
> -----Original Message-----
> From: shehzad.mirza@bt.com [mailto:shehzad.mirza@bt.com]
> Sent: Tuesday, October 23, 2001 6:25 AM
> To: yakov@juniper.net
> Cc: Lazer, Monica A, NNAD; ccamp@ops.ietf.org
> Subject: RE: Generalized Signaling - LSP Encoding Type expansion
>
> Yakov,
>
> See comments in-line
>
> > -----Original Message-----
> > From: Yakov Rekhter [SMTP:yakov@juniper.net]
> > Sent: 22 October 2001 21:12
> > To: Lazer, Monica A, NNAD
> > Cc: ccamp@ops.ietf.org
> > Subject: Re: Generalized Signaling - LSP Encoding Type expansion
> >
> > Monica,
> >
> > > Dimitri,
> > > Actually, it may be more accurate to put it differently - if GMPLS
> > supports
> > > only a handful of the services running on a given transport network,
> > than
> > > its value as a network's control plane component is diminished.
> >
> > To be even more accurate, GMPLS value is diminished *in the context*
> > of that particular transport network. And unless *all* providers
> > are going to run *all possible services* on their transport networks
> > (which is a somewhat unrealistic scenario), that means that the
> > value of GMPLS as a network's control plane component would be
> > diminished for *some*, but not *all* service providers.
> >
> >
> >
> [shehzad]
> For a control plane not to support all the transport services capable of
> being carried over an operator's network diminishes the value of that
> particular control plane. What is the point of having transparent/optical
> equipment capable of transporting both Gigabit Ethernet and Fiber Channel
> (as an example), if provisioning was based on signalling that could only
> support Gigabit Ethernet?
>
> This is a restriction for every provider regardless of whether a network
is
> a standalone one built for a large customer or a national network serving
> multiple customers. The effective 'banning' of certain services that are
> currently being offered by providers will unnecessarily damage the
business
> case for the adoption of GMPLS.
>
>
>
> > At the same time, it is important to keep in mind that being "all
> > things for all people" (aka as "perfect solution") is one of the
> > *non-goals* of GMPLS. So, it shouldn't come as a surprise if for a
> > *particular* provider GMPLS would *not* support *all* the services
> > that this provider runs on its transport network.
> >
> > Yakov.
> >
> >
> [Shehzad]
> There is no technical reason why a GMPLS encoding type could not be
> adopted for a recognised format such as Fiber Channel, as far as I am
aware
> the adoption of Fiber Channel is not likely to destroy the foundations of
> GMPLS.
>
> On a more general point, is the support of transport technologies
> within GMPLS signalling restricted to those that the authors of the GMPLS
> drafts will allow?
>
>
>
>
>
>
> > > Monica A. Lazer
> > > Advanced Transport Technology and Architecture Planning
> > >
> > > 908 234 8462
> > > mlazer@att.com
> > >
> > >
> > > -----Original Message-----
> > > From: Dimitri Papadimitriou
> > [mailto:dimitri.papadimitriou@alcatel.be]
> >
> > > Sent: Monday, October 22, 2001 3:15 PM
> > > To: Lazer, Monica A, NNAD
> > > Cc: Ewart Tempest; lberger@movaz.com; ccamp@ops.ietf.org
> > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion
> > >
> > > << File: Card for Dimitri Papadimitriou >> Hi Monica,
> > >
> > > Fine. Now we know the following: GMPLS is really attractive for
> > > carriers when it supports all transport technologies so it has
> > > to support Fiber Channel as well.
> > >
> > > I wasn't aware that Ewart was capable to read in your mind ;-)
> > >
> > > Regards,
> > > Dimitri.
> > >
> > > "Lazer, Monica A, NNAD" wrote:
> > > >
> > > > Dimitri,
> > > > I am just answering the PS question with this message.
> > > > The short answer is yes. The long answer is that the GMPLS control
> > plane
> > > is
> > > > really useful if it can support connection management for all the
> > > transport
> > > > services supported by the transport network using GMPLS. Therefore,
> > the
> > > > carrier services section for the NNI document to be posted on the
OIF
> > site
> > > > within a few minutes and the next draft of the carrier requirements
> > IETF
> > > > draft will both contain references to support of Fiber Channel.
> > > > Regards,
> > > > Monica A. Lazer
> > > > Advanced Transport Technology and Architecture Planning
> > > >
> > > > 908 234 8462
> > > > mlazer@att.com
> > > >
> > > > -----Original Message-----
> > > > From: Dimitri Papadimitriou
> > [mailto:dimitri.papadimitriou@alcatel.be]
> > > > Sent: Monday, October 22, 2001 2:47 PM
> > > > To: Ewart Tempest
> > > > Cc: lberger@movaz.com; ccamp@ops.ietf.org
> > > > Subject: Re: Generalized Signaling - LSP Encoding Type
> > expansion
> > > >
> > > > << File: Card for Dimitri Papadimitriou >> 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
> > >
>
> ------_=_NextPart_001_01C15BCA.5A2A5650
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Diso-8859-1">
> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
> 5.5.2654.19">
> <TITLE>RE: Generalized Signaling - LSP Encoding Type expansion </TITLE>
> </HEAD>
> <BODY>
>
> <P><FONT SIZE=3D2>All,</FONT>
> <BR><FONT SIZE=3D2>I am in full agreement with Shehzad. From a =
> carrier's perspective, the value of the control plane is in taking over =
> specific functions which currently reside in OSSs outside of the =
> network itself. Having only some applications, but not others of the =
> given function move into the network greatly diminishes the value of =
> having that function supported in the control plane. To be more =
> specific, if out of n services supported by the transport network, the =
> control plane supports automated provisioning of 1/2n services =
and the other 1/2n need support in the OSS, we still need to do the OSS =
> work for the given transport technology. So from a cost perspective, =
> now we have to ask ourselves whether we should pay for the provisioning =
> function twice.</FONT></P>
>
> <P><FONT SIZE=3D2>Regards,</FONT>
> </P>
>
> <P><FONT SIZE=3D2>Monica A. Lazer</FONT>
> <BR><FONT SIZE=3D2>Advanced Transport Technology and Architecture =
> Planning</FONT>
> </P>
>
> <P><FONT SIZE=3D2>908 234 8462</FONT>
> <BR><FONT SIZE=3D2>mlazer@att.com</FONT>
> </P>
> <BR>
>
> <P><FONT SIZE=3D2> -----Original Message-----</FONT>
> <BR><FONT SIZE=3D2>From: shehzad.mirza@bt.com [<A =
> HREF=3D"mailto:shehzad.mirza@bt.com";>mailto:shehzad.mirza@bt.com</A>] =
> </FONT>
> <BR><FONT SIZE=3D2>Sent: Tuesday, October 23, 2001 6:25 =
> AM</FONT>
> <BR><FONT SIZE=3D2>To: yakov@juniper.net</FONT>
> <BR><FONT SIZE=3D2>Cc: Lazer, Monica A, NNAD; =
> ccamp@ops.ietf.org</FONT>
> <BR><FONT SIZE=3D2>Subject: =
> RE: Generalized Signaling - LSP Encoding Type expansion </FONT>
> </P>
>
> <P><FONT SIZE=3D2>Yakov,</FONT>
> </P>
>
> <P><FONT SIZE=3D2>See comments in-line</FONT>
> </P>
>
> <P><FONT SIZE=3D2>> -----Original Message-----</FONT>
> <BR><FONT SIZE=3D2>> From: Yakov Rekhter =
> [SMTP:yakov@juniper.net]</FONT>
> <BR><FONT SIZE=3D2>> Sent: 22 October 2001 21:12</FONT>
> <BR><FONT SIZE=3D2>> To: Lazer, Monica A, NNAD</FONT>
> <BR><FONT SIZE=3D2>> Cc: ccamp@ops.ietf.org</FONT>
> <BR><FONT SIZE=3D2>> Subject: Re: =
> Generalized Signaling - LSP Encoding Type expansion </FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> Monica,</FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> > Dimitri,</FONT>
> <BR><FONT SIZE=3D2>> > Actually, it may be more accurate to put =
> it differently - if GMPLS</FONT>
> <BR><FONT SIZE=3D2>> supports</FONT>
> <BR><FONT SIZE=3D2>> > only a handful of the services running on =
> a given transport network,</FONT>
> <BR><FONT SIZE=3D2>> than</FONT>
> <BR><FONT SIZE=3D2>> > its value as a network's control plane =
> component is diminished. </FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> To be even more accurate, GMPLS value is =
> diminished *in the context*</FONT>
> <BR><FONT SIZE=3D2>> of that particular transport network. And =
> unless *all* providers</FONT>
> <BR><FONT SIZE=3D2>> are going to run *all possible services* on =
> their transport networks</FONT>
> <BR><FONT SIZE=3D2>> (which is a somewhat unrealistic scenario), =
> that means that the</FONT>
> <BR><FONT SIZE=3D2>> value of GMPLS as a network's control plane =
> component would be</FONT>
> <BR><FONT SIZE=3D2>> diminished for *some*, but not *all* service =
> providers.</FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR> <FONT =
> SIZE=3D2>[shehzad] </FONT>
> <BR><FONT SIZE=3D2>For a control plane not to support all the transport =
> services capable of</FONT>
> <BR><FONT SIZE=3D2>being carried over an operator's network diminishes =
> the value of that</FONT>
> <BR><FONT SIZE=3D2>particular control plane. What is the point of =
> having transparent/optical</FONT>
> <BR><FONT SIZE=3D2>equipment capable of transporting both Gigabit =
> Ethernet and Fiber Channel</FONT>
> <BR><FONT SIZE=3D2>(as an example), if provisioning was based on =
> signalling that could only</FONT>
> <BR><FONT SIZE=3D2>support Gigabit Ethernet?</FONT>
> </P>
>
> <P><FONT SIZE=3D2>This is a restriction for every provider regardless =
> of whether a network is</FONT>
> <BR><FONT SIZE=3D2>a standalone one built for a large customer or a =
> national network serving</FONT>
> <BR><FONT SIZE=3D2>multiple customers. The effective 'banning' of =
> certain services that are</FONT>
> <BR><FONT SIZE=3D2>currently being offered by providers will =
> unnecessarily damage the business</FONT>
> <BR><FONT SIZE=3D2>case for the adoption of GMPLS.</FONT>
> </P>
> <BR>
> <BR>
>
> <P><FONT SIZE=3D2>> At the same time, it is important to keep in =
> mind that being "all</FONT>
> <BR><FONT SIZE=3D2>> things for all people" (aka as =
> "perfect solution") is one of the</FONT>
> <BR><FONT SIZE=3D2>> *non-goals* of GMPLS. So, it shouldn't come as =
> a surprise if for a</FONT>
> <BR><FONT SIZE=3D2>> *particular* provider GMPLS would *not* support =
> *all* the services</FONT>
> <BR><FONT SIZE=3D2>> that this provider runs on its transport =
> network.</FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> Yakov.</FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR> <FONT =
> SIZE=3D2>[Shehzad]</FONT>
> <BR> <FONT SIZE=3D2>There is =
> no technical reason why a GMPLS encoding type could not be</FONT>
> <BR><FONT SIZE=3D2>adopted for a recognised format such as Fiber =
> Channel, as far as I am aware</FONT>
> <BR><FONT SIZE=3D2>the adoption of Fiber Channel is not likely to =
> destroy the foundations of</FONT>
> <BR><FONT SIZE=3D2>GMPLS.</FONT>
> </P>
>
> <P> <FONT SIZE=3D2>On a more =
> general point, is the support of transport technologies</FONT>
> <BR><FONT SIZE=3D2>within GMPLS signalling restricted to those that the =
> authors of the GMPLS</FONT>
> <BR><FONT SIZE=3D2>drafts will allow? </FONT>
> <BR> <FONT SIZE=3D2> =
> </FONT>
> </P>
> <BR>
> <BR>
> <BR>
> <BR>
>
> <P><FONT SIZE=3D2>> > Monica A. Lazer</FONT>
> <BR><FONT SIZE=3D2>> > Advanced Transport Technology and =
> Architecture Planning</FONT>
> <BR><FONT SIZE=3D2>> > </FONT>
> <BR><FONT SIZE=3D2>> > 908 234 8462</FONT>
> <BR><FONT SIZE=3D2>> > mlazer@att.com</FONT>
> <BR><FONT SIZE=3D2>> > </FONT>
> <BR><FONT SIZE=3D2>> > </FONT>
> <BR><FONT SIZE=3D2>> > -----Original Message-----</FONT>
> <BR><FONT SIZE=3D2>> > From: =
> Dimitri Papadimitriou</FONT>
> <BR><FONT SIZE=3D2>> [<A =
> HREF=3D"mailto:dimitri.papadimitriou@alcatel.be";>mailto:dimitri.papadimi=
> triou@alcatel.be</A>]</FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> > Sent: =
> Monday, October 22, 2001 3:15 PM</FONT>
> <BR><FONT SIZE=3D2>> > To: Lazer, Monica A, NNAD</FONT>
> <BR><FONT SIZE=3D2>> > Cc: Ewart Tempest; lberger@movaz.com; =
> ccamp@ops.ietf.org</FONT>
> <BR><FONT SIZE=3D2>> > Subject: Re: Generalized =
> Signaling - LSP Encoding Type expansion</FONT>
> <BR><FONT SIZE=3D2>> > </FONT>
> <BR><FONT SIZE=3D2>> > << File: Card for Dimitri =
> Papadimitriou >> Hi Monica,</FONT>
> <BR><FONT SIZE=3D2>> > </FONT>
> <BR><FONT SIZE=3D2>> > Fine. Now we know the following: GMPLS is =
> really attractive for </FONT>
> <BR><FONT SIZE=3D2>> > carriers when it supports all transport =
> technologies so it has </FONT>
> <BR><FONT SIZE=3D2>> > to support Fiber Channel as well.</FONT>
> <BR><FONT SIZE=3D2>> > </FONT>
> <BR><FONT SIZE=3D2>> > I wasn't aware that Ewart was capable to =
> read in your mind ;-)</FONT>
> <BR><FONT SIZE=3D2>> > </FONT>
> <BR><FONT SIZE=3D2>> > Regards,</FONT>
> <BR><FONT SIZE=3D2>> > Dimitri.</FONT>
> <BR><FONT SIZE=3D2>> > </FONT>
> <BR><FONT SIZE=3D2>> > "Lazer, Monica A, NNAD" =
> wrote:</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > Dimitri,</FONT>
> <BR><FONT SIZE=3D2>> > > I am just answering the PS question =
> with this message.</FONT>
> <BR><FONT SIZE=3D2>> > > The short answer is yes. The =
> long answer is that the GMPLS control</FONT>
> <BR><FONT SIZE=3D2>> plane</FONT>
> <BR><FONT SIZE=3D2>> > is</FONT>
> <BR><FONT SIZE=3D2>> > > really useful if it can support =
> connection management for all the</FONT>
> <BR><FONT SIZE=3D2>> > transport</FONT>
> <BR><FONT SIZE=3D2>> > > services supported by the transport =
> network using GMPLS. Therefore,</FONT>
> <BR><FONT SIZE=3D2>> the</FONT>
> <BR><FONT SIZE=3D2>> > > carrier services section for the NNI =
> document to be posted on the OIF</FONT>
> <BR><FONT SIZE=3D2>> site</FONT>
> <BR><FONT SIZE=3D2>> > > within a few minutes and the next =
> draft of the carrier requirements</FONT>
> <BR><FONT SIZE=3D2>> IETF</FONT>
> <BR><FONT SIZE=3D2>> > > draft will both contain references to =
> support of Fiber Channel.</FONT>
> <BR><FONT SIZE=3D2>> > > Regards,</FONT>
> <BR><FONT SIZE=3D2>> > > Monica A. Lazer</FONT>
> <BR><FONT SIZE=3D2>> > > Advanced Transport Technology and =
> Architecture Planning</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > 908 234 8462</FONT>
> <BR><FONT SIZE=3D2>> > > mlazer@att.com</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > -----Original =
> Message-----</FONT>
> <BR><FONT SIZE=3D2>> > > From: Dimitri =
> Papadimitriou</FONT>
> <BR><FONT SIZE=3D2>> [<A =
> HREF=3D"mailto:dimitri.papadimitriou@alcatel.be";>mailto:dimitri.papadimi=
> triou@alcatel.be</A>]</FONT>
> <BR><FONT SIZE=3D2>> > > Sent: Monday, October 22, =
> 2001 2:47 PM</FONT>
> <BR><FONT SIZE=3D2>> > > To: Ewart =
> Tempest</FONT>
> <BR><FONT SIZE=3D2>> > > Cc: =
> lberger@movaz.com; ccamp@ops.ietf.org</FONT>
> <BR><FONT SIZE=3D2>> > > =
> Subject: Re: Generalized =
> Signaling - LSP Encoding Type</FONT>
> <BR><FONT SIZE=3D2>> expansion</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > << File: Card for Dimitri =
> Papadimitriou >> Hi Ewart,</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > If you take a look on the IEEE =
> Standards you will see</FONT>
> <BR><FONT SIZE=3D2>> > > that GE is referred to as</FONT>
> <BR><FONT SIZE=3D2>> > > - 802.3z for 1Gbps (see below [1]) =
> same exists for copper 802.3ab</FONT>
> <BR><FONT SIZE=3D2>> > > - 802.3ae for 10Gbps (see below =
> [2])</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > So my question is what do you have in =
> mind ? to separate</FONT>
> <BR><FONT SIZE=3D2>> > > these values ?</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > Thanks,</FONT>
> <BR><FONT SIZE=3D2>> > > Dimitri.</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > PS: for FiberChannel sorry i am not =
> an expert but is someone</FONT>
> <BR><FONT SIZE=3D2>> > > targeting to =
> use GMPLS for FiberChannel LSP ?</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > -------</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > [1] From - <A =
> HREF=3D"http://standards.ieee.org"; =
> TARGET=3D"_blank">http://standards.ieee.org</A></FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > Project scope: Define Carrier Sense =
> Multiple Access with Collision</FONT>
> <BR><FONT SIZE=3D2>> > > Detection (CSMA/CD) Media Access =
> Control (MAC) parameters and minimal</FONT>
> <BR><FONT SIZE=3D2>> > > augmentation of its operation, =
> physical layer characteristics,</FONT>
> <BR><FONT SIZE=3D2>> repeater</FONT>
> <BR><FONT SIZE=3D2>> > > functions and management parameters =
> for transfer of 802.3 and Ethernet</FONT>
> <BR><FONT SIZE=3D2>> > > format frames at 1,000 Mb/s.</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > Project purpose: The purpose of this =
> project is to extend the 802.3</FONT>
> <BR><FONT SIZE=3D2>> > > protocol to an operating speed of =
> 1,000 Mb/s in order to provide a</FONT>
> <BR><FONT SIZE=3D2>> > > significant increase in bandwidth =
> while maintaining maximum</FONT>
> <BR><FONT SIZE=3D2>> > > compatibility</FONT>
> <BR><FONT SIZE=3D2>> > > with the installed base of CSMA/CD =
> nodes, previous investment in</FONT>
> <BR><FONT SIZE=3D2>> > > research</FONT>
> <BR><FONT SIZE=3D2>> > > and development, and principles of =
> network operation and management.</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > [2] From - <A =
> HREF=3D"http://standards.ieee.org"; =
> TARGET=3D"_blank">http://standards.ieee.org</A></FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > Project scope: Define 802.3 Media =
> Access Control (MAC) parameters and</FONT>
> <BR><FONT SIZE=3D2>> > > minimal augmentation of its =
> operation, physical layer characteristics</FONT>
> <BR><FONT SIZE=3D2>> > > and management parameters for =
> transfer of LLC and Ethernet format</FONT>
> <BR><FONT SIZE=3D2>> > > frames at 10 Gb/s using full duplex =
> operation as defined in the 802.3</FONT>
> <BR><FONT SIZE=3D2>> > > standard. In addition to the =
> traditional LAN space, add parameters and</FONT>
> <BR><FONT SIZE=3D2>> > > mechanisms that enable deployment of =
> Ethernet over the Wide Area</FONT>
> <BR><FONT SIZE=3D2>> Network</FONT>
> <BR><FONT SIZE=3D2>> > > operating at a data rate compatible =
> with OC-192c and SDH VC-4-64c</FONT>
> <BR><FONT SIZE=3D2>> > > payload</FONT>
> <BR><FONT SIZE=3D2>> > > rate.</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > Project purpose: The purpose of this =
> project is to extend the 802.3</FONT>
> <BR><FONT SIZE=3D2>> > > protocol to an operating speed of 10 =
> Gb/s and to expand the Ethernet</FONT>
> <BR><FONT SIZE=3D2>> > > application space to include Wide =
> Area Network links in order to</FONT>
> <BR><FONT SIZE=3D2>> provide</FONT>
> <BR><FONT SIZE=3D2>> > > a significant increase in bandwidth =
> while maintaining maximum</FONT>
> <BR><FONT SIZE=3D2>> > > compatibility</FONT>
> <BR><FONT SIZE=3D2>> > > with the installed base of 802.3 =
> interfaces, previous investment in</FONT>
> <BR><FONT SIZE=3D2>> > > research</FONT>
> <BR><FONT SIZE=3D2>> > > and development, and principles of =
> network operation and management.</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > -------</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > > Ewart Tempest wrote:</FONT>
> <BR><FONT SIZE=3D2>> > > ></FONT>
> <BR><FONT SIZE=3D2>> > > > Lou,</FONT>
> <BR><FONT SIZE=3D2>> > > ></FONT>
> <BR><FONT SIZE=3D2>> > > > Within section 3.1.1 of =
> draft-ietf-mpls-generalized-signaling-06 can</FONT>
> <BR><FONT SIZE=3D2>> > > > you please add additonal LSP =
> Encoding Types for GE and FiberChannel.</FONT>
> <BR><FONT SIZE=3D2>> > > > GE is not really covered by the =
> existing Ethernet related encoding</FONT>
> <BR><FONT SIZE=3D2>> > > > types, and FiberChannel is not =
> covered at all. Thanks.</FONT>
> <BR><FONT SIZE=3D2>> > > ></FONT>
> <BR><FONT SIZE=3D2>> > > > Ewart</FONT>
> <BR><FONT SIZE=3D2>> > </FONT>
> </P>
>
> </BODY>
> </HTML>
> ------_=_NextPart_001_01C15BCA.5A2A5650--