[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: End-to-end L2-LSP
Dear Richard,
See in-line please,
>Thank you for taking the time to respond to my questions. I anticipated
>that your response would include "over-provisioning is the best answer"
>to decrease the chance of congestion on non-GMPLS switches.
>This is what is done in the LAN environment today in conjunction with CoS,
>and this is why I believe there will be two opposing views on how
>far L2-LSP connections should be extended down to the user. One view
>is that over provisioning and CoS work fine in the enterprise network today,
>and therefore the L2-LSP should only be extended down to the point
>at which the enterprise network connects to the SP network,
>e.g. Ethernet DSLAM. I think the other view will be that over provisioning
>and CoS in the enterprise network don't work and therefore L2-LSPs
>should be provided end-to-end using only GMPLS capable switches.
>I wouldn't have thought there would be much call for mixed
>GMPLS/non-GMPLS enterprise networks (except for during migration)
>due to the opposing views, e.g. if over provisioning is good enough for
>one switch, why isn't it good enough for the other?
Over-provisioned network is non-guaranteed network. It can't prevent
occasional congestion at any rate. Further, network condition in private
network is very diverse. You can't predict minimum service level
inside every private network.
Suppose that an ISP want to provide high-quality, video-phone service
for enterprise users. Nothing can be guaranteed inside the over-provisioned
customer network. If the service level is not satisfactory, customers will complain
to service provider even if the main cause is in his network or destination network.
We need some structure that coordinate service quality in both private sector,
as well as in public sector consistently.
An end-to-end signal is an effective means to communicate between
user terminal, private switches and provider switches, and concert service
quality at each different operations network. This is a goal that RSVP (RFC2205)
pursued, however ineffective in local network because Ethernet industry
didn't support RSVP over Ethernet (RFC2814, 2815, 2816).
Now we have another opportunity to realize the goal using L2-LSP.
Therefore, I believe end-to-end LSP is necessary even in enterprise network
for the purpose of providing guaranteed commercial service.
>I think where most people will agree is that using connections
>in the SPs access network does make sense in order to provide efficient
>link utilisation and per connection policing to ensure one customers
>traffic can not affect another's. Regarding the ability to set up new
>connections based on a request from the user (rather than constraining
>RSVP signalling to inside the SP network), I think this will come
>down to enterprise customer demand for improved service performance.
>If a customer wasn't getting the performance they needed from their
>SP and was offered a new service that allowed them to setup new L2-LSP
>connections on demand that would offer better performance (e.g. for voice
>calls or video conferences), then upgrading the user devices to support
>the new service could well be an attractive proposition. If on the other
Yes, this will be one of prospective service newly enabled using L2-LSP.
>hand a customer buys a best effort service and considers the performance
>to be 'good enough', then there would be no reason to go to the expense
>of upgrading the user devices to support the set up of L2-LSPs.
Ever increasing besteffort bandwidth will eventually not satisfy
both providers and customers for many reasons. Service providers
will have difficulty in collecting expenses enough to invest on increased
bandwidth. This will in turn gradually downgrade overall communication quality,
and applications requiring real-time service will never satisfy customers.
We already see such symptom in some low-price service providers.
I believe new service structure that can provide difference of service
quality will offer benefit to customers, providers as well as vendors in the end.
I also look forward to see you at Paris and continue helpful discussion.
Sincerely
Jaihyung
Dr. Jaihyung Cho
ETRI, Korea
phone : 042) 860-5514
oversea: +82-42-860-5514
fax: +82-42-861-5550
-----?? ???-----
?? ??: "richard.spencer@bt.com" <richard.spencer@bt.com>
?? ??: 2005-07-14 ?? 1:10:30
?? ??: "jaihyung@etri.re.kr" <jaihyung@etri.re.kr>, "ccamp@ops.ietf.org" <ccamp@ops.ietf.org>
??:
??: RE: End-to-end L2-LSP
Jaihyung,
Thank you for taking the time to respond to my questions. I anticipated that your response would include "over-provisioning is the best answer" to decrease the chance of congestion on non-GMPLS switches. This is what is done in the LAN environment today in conjunction with CoS, and this is why I believe there will be two opposing views on how far L2-LSP connections should be extended down to the user. One view is that over provisioning and CoS work fine in the enterprise network today, and therefore the L2-LSP should only be extended down to the point at which the enterprise network connects to the SP network, e.g. Ethernet DSLAM. I think the other view will be that over provisioning and CoS in the enterprise network don't work and therefore L2-LSPs should be provided end-to-end using only GMPLS capable switches. I wouldn't have thought there would be much call for mixed GMPLS/non-GMPLS enterprise networks (except for during migration) due to the opposing views, e.g. if over provisioning is good enough for one switch, why isn't it good enough for the other?
I think where most people will agree is that using connections in the SPs access network does make sense in order to provide efficient link utilisation and per connection policing to ensure one customers traffic can not affect another's. Regarding the ability to set up new connections based on a request from the user (rather than constraining RSVP signalling to inside the SP network), I think this will come down to enterprise customer demand for improved service performance. If a customer wasn't getting the performance they needed from their SP and was offered a new service that allowed them to setup new L2-LSP connections on demand that would offer better performance (e.g. for voice calls or video conferences), then upgrading the user devices to support the new service could well be an attractive proposition. If on the other hand a customer buys a best effort service and considers the performance to be 'good enough', then there would be no reason to go to the expense of upgrading the user devices to support the set up of L2-LSPs.
I look forward to the discussions in Paris.
Regards,
Richard
> -----Original Message-----
> From: CHO, JAI HYUNG [mailto:jaihyung@etri.re.kr]
> Sent: 13 July 2005 15:14
> To: Spencer,R,Richard,XDE73 R; ccamp@ops.ietf.org
> Subject: RE: End-to-end L2-LSP
>
>
>
>
> Dear Richard Spencer
>
> see in-line
>
> >Jaihyung,
> >
> >Perhaps I'm becoming too much of a pessimist;-)
>
> oh, not at all,
> you are reasonable enough to dig up unclear knowledge
> please go ahead until you finally get satisfactory answer.
>
>
> >Ignoring the commercial aspects, please can you help clarify
> a few technical
> >questions I have in order to help me gain a better
> understanding of the proposal?
> >
> >1. You say that one of the key reasons for using GMPLS in
> the enterprise
> >network is to provide end-to-end QoS control. However, you
> also say that not
> >all the switches will need to support GMPLS, only those at
> bottle necks.
> >Please can you expand on this to explain how you can have end-to-end
> >QoS control when the L2-LSP is not end-to-end?
>
>
> The contextual meaning of 'End-to-end LSP' is that GMPLS label is
> assigned from source terminal and removed at destination terminal,
> because RSVP-TE message is exchanged from host to host.
> It may not perfectly guarantee QoS when the GMPLS deployment
> is not complete, however it will at least be good enough
> for end-user applications to tell those GMPLS implemented L2 switches
> what frame must be given priority service when congestion occur.
>
>
> >As being discussed
> >on the PWE3 mailing list, the performance a service receives
> is only as
> >good as the worst performing server layer. Therefore, if there is a
> >standard 802.1 workgroup switch between the user and the
> L2-LSP that is
> >experiencing congestion (e.g. due to a large amount of
> peer-to-peer traffic),
> >then the QoS that the user receives will only be as good as
> that provided
> >by the congested workgroup switch.
>
>
> of course, ETH-GMPLS does not prevent congestion inevitably occurring
> in those non-GMPLS deployed part.
>
>
> >The only way I can see a network using a mixture of GMPLS
> and non-GMPLS
> >switches guaranteeing end-to-end QoS would be to design the
> network in
> >such a way that the non-GMPLS switches could never become congested.
>
>
> Yes, that will be the way wise network designer improve their network.
>
>
> >To do this would require that RSVP requests be used for ALL
> traffic flows
> >to ensure that there was enough bandwidth available, along
> with strict
> >per L2-LSP policing on the user devices (e.g. PC).
> >However, the obvious flaw in this approach is that someone could
> >just come along and connect
> >an end device to a non-GMPLS switch and start transmitting traffic
> >(without performing CAC/policing) causing the switch to
> become congested.
> >Therefore, please can you explain how end-to-end QoS can be
> guaranteed
> >in a mixed non-GMPLS and GMPLS switching environment?
>
>
> Of course traffic came from non controlled ingress can not be
> prevented
> in non-GMPLS node. There's no magic. Only the
> over-provisioning is the
> best answer. However, once the aggregated traffic pass 'ANY' one of
> GMPLS enabled node, those uncontrolled traffic will suffer
> queuing discipline.
>
>
> >2. Section 5.1 currently states "When the customer initiates
> data transmission,
> >the access switch maps the user flow into the L2 LSP.
> Mapping procedure is
> >subject to implementation choices, and is out of the scope of this
> >document." In order to be able to map any traffic, first of
> all the switch needs
> >to know what type of traffic (e.g. based on source/dest MAC,
> VLAN ID, 802.1p
> >bits, etc) should be mapped to the L2-LSP. In Figure 1, if
> an L2-LSP is set up
> >from the DSLAM to the edge router based on a request from
> the user (e.g. via
> >a PC or VoIP phone), then won't the user also need to signal
> what type of
> >traffic should to be mapped to the L2-LSP?
>
>
> Thank you for pointing out important thing.
> That's the most unfortunate part I reluctantly agreed because the
> work condition in the framework DT was not to span L2-LSP
> beyond provider network.
> As you noticed, mapping user traffic at provider access is awkward.
> A smooth method will be for user terminal aware of the L2 label
> to use by receiving RSVP-TE message.
> However, there was strong argument that RSVP-TE must not
> go beyond provider network because the DT is not chartered
> to work in customer network.
> That's why I requested amendment of CCAMP charter
> to include user terminal explicitly in CCAMP work scope, so that
> avoid such silly argument in future.
>
>
> >3. In section 5.1, the text states that the aggregation
> switch between the
> >DSLAM and edge router may be a 802.1 switch, i.e. it doesn't
> have to support
> >GMPLS. To set up a connection, first of all there needs to
> be a data plane
> >capable of carrying control plane traffic between GMPLS
> peers. Secondly,
> >the GMPLS peers need reachability information in order to
> forward control
> >messages onto the next peer (i.e. a static or IGP route). If
> the GMPLS peers
> >(e.g. the DSLAM and edge router in Figure 1) are not
> directly connected,
> >then the GMPLS control packets will need to be forwarded by
> the 802.1 switch.
> >Would the idea be to have say a "control traffic VLAN"
> configured between the
> >DSLAM and edge router via the transit 802.1 switch so that
> control packets
> >could be forwarded transparently by the 802.1 switch?
>
>
> Although it doesn't preclude use of VLAN, I think such
> special configuration
> for RSVP-TE control message is not necessary in legacy switches.
> Legacy switches only need to pass RSVP-TE messages as they
> pass normal data frames. Only the GMPLS implemented switches
> need to distinguish frames containing RSVP-TE messages and
> snoop them.
> Detail of implementation is, of course, for future discussion.
>
>
> >4. If we assume that control messages can be transparently forwarded
> >by the intermediate 802.1 aggregation switch then how are
> user frames
> >forwarded in the data plane by the 802.1 switch?
>
>
> Legacy switches do not distinguish control/data frames.
>
>
> >If the DSLAM sets up a L2-LSP
> >to the edge router using say VLAN ID 99, how does the switch
> know that any
> >packets coming in with a VLAN ID of 99 should be forwarded
> out of the port
> >connecting to the edge router?
>
>
> oh, you misunderstood the L2-LSP.
> The question you are asking depends on how L2 label is encoded.
> there was hot debate in the DT about the issue how L2 label
> is encoded.
> My proposal is to use part of MAC address for label and the
> other people
> argued to use VLAN ID for label. The debate was not concluded
> because the goal of the L2SC framework document is not to select
> implementation method but to draw necessary work scope.
> I believe this issue will be dealt in depth after Paris meeting.
> So, please reserve your question until then and ask to those
> VLAN proponents.
>
>
> >5. During connection setup, I take it that the GMPLS peers
> assume that
> >resources are available within the intermediate 802.1 switch
> to support
> >the connection (as its transparent). However, as there is no
> >CAC/policing being performed by the 802.1 switch
> >(the L2-LSPs are transparent), and due to the any-to-any and
> broadcast
> >based nature of Ethernet (i.e. its CL properties), then how can this
> >assumption be made? This comes back to my original question, how
> >can end-to-end QoS be guaranteed in an environment where there is
> >a mixture of 802.1 and GMPLS enabled switches?
>
>
> yes, you came back to the question I answered in above ;-)
> so, please see above.
> GMPLS enabled nodes must be positioned at points congestion
> is likely to be expected.
>
> Thanks
>
> Jaihyung
>
>
> ============================================
>
>
>
> -----?? ???-----
> ?? ??: "richard.spencer@bt.com" <richard.spencer@bt.com>
> ?? ??: 2005-07-13 ?? 8:53:13
> ?? ??: "jaihyung@etri.re.kr" <jaihyung@etri.re.kr>,
> "ccamp@ops.ietf.org" <ccamp@ops.ietf.org>
> ??:
> ??: RE: End-to-end L2-LSP
>
>
>
>
> Jaihyung,
>
> Perhaps I'm becoming too much of a pessimist;-) Ignoring the
> commercial aspects, please can you help clarify a few
> technical questions I have in order to help me gain a better
> understanding of the proposal?
>
> 1. You say that one of the key reasons for using GMPLS in the
> enterprise network is to provide end-to-end QoS control.
> However, you also say that not all the switches will need to
> support GMPLS, only those at bottle necks. Please can you
> expand on this to explain how you can have end-to-end QoS
> control when the L2-LSP is not end-to-end? As being discussed
> on the PWE3 mailing list, the performance a service receives
> is only as good as the worst performing server layer.
> Therefore, if there is a standard 802.1 workgroup switch
> between the user and the L2-LSP that is experiencing
> congestion (e.g. due to a large amount of peer-to-peer
> traffic), then the QoS that the user receives will only be as
> good as that provided by the congested workgroup switch.
>
> The only way I can see a network using a mixture of GMPLS and
> non-GMPLS switches guaranteeing end-to-end QoS would be to
> design the network in such a way that the non-GMPLS switches
> could never become congested. To do this would require that
> RSVP requests be used for ALL traffic flows to ensure that
> there was enough bandwidth available, along with strict per
> L2-LSP policing on the user devices (e.g. PC). However, the
> obvious flaw in this approach is that someone could just come
> along and connect an end device to a non-GMPLS switch and
> start transmitting traffic (without performing CAC/policing)
> causing the switch to become congested. Therefore, please can
> you explain how end-to-end QoS can be guaranteed in a mixed
> non-GMPLS and GMPLS switching environment?
>
> 2. Section 5.1 currently states "When the customer initiates
> data transmission, the access switch maps the user flow into
> the L2 LSP. Mapping procedure is subject to implementation
> choices, and is out of the scope of this document." In order
> to be able to map any traffic, first of all the switch needs
> to know what type of traffic (e.g. based on source/dest MAC,
> VLAN ID, 802.1p bits, etc) should be mapped to the L2-LSP. In
> Figure 1, if an L2-LSP is set up from the DSLAM to the edge
> router based on a request from the user (e.g. via a PC or
> VoIP phone), then won't the user also need to signal what
> type of traffic should to be mapped to the L2-LSP?
>
> 3. In section 5.1, the text states that the aggregation
> switch between the DSLAM and edge router may be a 802.1
> switch, i.e. it doesn't have to support GMPLS. To set up a
> connection, first of all there needs to be a data plane
> capable of carrying control plane traffic between GMPLS
> peers. Secondly, the GMPLS peers need reachability
> information in order to forward control messages onto the
> next peer (i.e. a static or IGP route). If the GMPLS peers
> (e.g. the DSLAM and edge router in Figure 1) are not directly
> connected, then the GMPLS control packets will need to be
> forwarded by the 802.1 switch. Would the idea be to have say
> a "control traffic VLAN" configured between the DSLAM and
> edge router via the transit 802.1 switch so that control
> packets could be forwarded transparently by the 802.1 switch?
>
> 4. If we assume that control messages can be transparently
> forwarded by the intermediate 802.1 aggregation switch then
> how are user frames forwarded in the data plane by the 802.1
> switch? If the DSLAM sets up a L2-LSP to the edge router
> using say VLAN ID 99, how does the switch know that any
> packets coming in with a VLAN ID of 99 should be forwarded
> out of the port connecting to the edge router?
>
> 5. During connection setup, I take it that the GMPLS peers
> assume that resources are available within the intermediate
> 802.1 switch to support the connection (as its transparent).
> However, as there is no CAC/policing being performed by the
> 802.1 switch (the L2-LSPs are transparent), and due to the
> any-to-any and broadcast based nature of Ethernet (i.e. its
> CL properties), then how can this assumption be made? This
> comes back to my original question, how can end-to-end QoS be
> guaranteed in an environment where there is a mixture of
> 802.1 and GMPLS enabled switches?
>
> Thanks,
> Richard
>
> > -----Original Message-----
> > From: CHO, JAI HYUNG [mailto:jaihyung@etri.re.kr]
> > Sent: 12 July 2005 09:21
> > To: Spencer,R,Richard,XDE73 R; ccamp@ops.ietf.org
> > Subject: RE: End-to-end L2-LSP
> >
> >
> >
> >
> > Dear Richard,
> >
> > Yes, I believe it is not only commercially profitable but it
> > may also grow total
> > revenue of service operators by introducing new services.
> >
> > For example, think the example of IP phone you referred.
> > How do you think you can provide reliable VoIP service and
> > safely authenticate phone users and charge fees as counted by
> > packet usage
> > using simple Ethernet based xDSL network ?
> >
> > There's hardly new service that providers may offer using
> > Ethernet based
> > architecture, and collect sufficient profit to investment.
> >
> > A sophisticated ATM switch might do the work if it is not
> expensive.
> > However, my intension is modifiying existing design of
> > Ethernet hardware
> > with a little bit additional cost, and provide the level of
> > service that
> > ATM switches might offer.
> >
> > We have initial design of the Ethernet-MPLS hardware. I don't think
> > GMPLS enabled Ethernet switch will be so complex. The market price
> > of GMPLS enabled switch will not be so expensive than normal
> > Ethernet switches.
> >
> > Further, it only requires upgrade of switches in some
> > bottleneck points of network.
> > Read the framework documents of L2SC. It doesn't require
> > entire replacement
> > of switches to introduce new service.
> >
> > Every year, ISPs purchase new access switches and replaces
> > old machines.
> > With a bit additional cost, ISPs may use the GMPLS enabled
> switch for
> > normal Ethernet switching in initial deployment.
> >
> > When the GMPLS function is enabled in some upgraded part of
> network,
> > ISPs may provide high quality, reliable VoIP service to
> xDSL customers
> > using RSVP-TE enabled VoIP phone.
> > The high quality video-phone service enabled by GMPLS will be
> > competable to legacy voice only phone service.
> >
> >
> > There are lots of things I can argue about commercial aspects
> > of this technique.
> > However I don't think it is not appropriate to discuss this
> > issue in this mailing list.
> > All I can say is,
> > yes, I believe that it may be commercially viable.
> >
> >
> > Thanks
> >
> > Jaihyung
> >
> > ================================================
> >
> > Do you really think the benefits of extended GMPLS down to
> > the end user could ever justify the costs involved in
> > upgrading LAN switches and things like IP phones (simple low
> > cost commodity items) to support GMPLS signalling/routing?
> >
> > Your proposal may be technically possible (though it would
> > require new hardware and significant software upgrades), but
> > commercially I would consider this to be a non-starter.
> >
> > Regards,
> > Richard
> >
> > > -----Original Message-----
> > > From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org]On
> > > Behalf Of CHO, JAI HYUNG
> > > Sent: 12 July 2005 01:10
> > > To: ccamp@ops.ietf.org
> > > Subject: End-to-end L2-LSP
> > >
> > >
> > >
> > > Dear all,
> > >
> > > Greetings.
> > >
> > > I am a co-editor of the Ethernet-GMPLS framework document.
> > > (draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt)
> > >
> > > I am writing this to explain the motivation behind the
> > > proposal of scenario-1, and to raise the issue of
> > > end-to-end LSP to be included in CCAMP charter.
> > >
> > > An important goal intended in scenario-1 is
> > > QoS control over end-to-end packet delivery using LSP.
> > > In other words, the purpose of scenario-1 is extending coverage
> > > of GMPLS control including customer network and end-user device,
> > > such as PC, VoIP phone, IP-TV, or even future 4G mobile phone.
> > > End-user applications will have a means to request resources
> > > to network using GMPLS signal.
> > >
> > > Unfortunately, this view is not included in the
> > > framework because there was strong opinion that
> > > L2-LSP must not span beyond provider network because
> > > CCAMP is not chartered to work on customer
> > > network. I am wondering if this is right argument.
> > > Perhaps the charter can be amended to include this work.
> > >
> > > I believe there is little technical reason to preclude
> > > LSP being used in customer network. It is a reasonable
> > > assumption that private company may also use GMPLS
> > > implemented Ethernet switch, once the L2SC work is successful.
> > > Currently, CCAMP is the only place discussing the matter of
> > > Ethernet and LSP. There is no other WG dealing similar issue.
> > > If CCAMP wants to work on Ethernet,
> > > I think the coverage of common GMPLS control must be
> > > extended to include all area where Ethernet is deployed.
> > > Currently, Ethernet is dominantly deployed in first-mile
> > > network where access network as well as customer network
> > > and user hosts are usually included. Therefore, user host must
> > > be considered as initiation and termination point of L2-LSP.
> > >
> > > Another important reason to include user host in CCAMP
> > > work scope is to achieve consistent end-to-end control of QoS.
> > > End-to-end QoS has long been desired goal since RSVP was
> > > first designed. This goal can be best achieved using
> > > end-to-end GMPLS signal and L2-LSP.
> > > Currently, RSVP (RFC2205) is available in many user hosts.
> > > There is only a little difference between RSVP and RSVP-TE.
> > > If the RSVP-TE signal of provider network can reach user host
> > > across Ethernet based private network, an LSP can be established
> > > from application to application via the provider backbone.
> > > Service providers will be able to control application flows
> > > in L2-LSP level as well as in aggregated LSP pipe of similar
> > > application type. A variety of new services will be enabled using
> > > the enhanced capability of distinguishing and controlling each
> > > individual application flow.
> > >
> > > I personally believe that end-to-end L2-LSP may offer
> > > innovative solutions for servicing IP-TV as well as fast
> mobility.
> > > There have been some experimental approaches combining
> > > MPLS and IP mobility. However such potential of the new
> > > application can only be explored when end-user host is
> > > included in the scope of CCAMP work area.
> > >
> > > Therefore, I hereby sincerely request people's attention
> > > and support on this perspective of end-to-end LSP.
> > > If there is enough number of people agree on this view,
> > > the WG can request the necessary update of the charter.
> > >
> > > Thank you.
> > >
> > > Jaihyung Cho
> > >
> > >
> > >
> > > ETRI, Korea
> > > phone : 042) 860-5514
> > > oversea: +82-42-860-5514
> > > fax: +82-42-861-5550
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>