[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PWE3] PWE3 question
Any transport network first installs equipment and fibers based on a network
planning result. These physical resources are installed before any traffic is
being carried.
After the physical resources are installed and a first level of connectivity is
available, the next layers in the network are "installed". I.e. trails are set
up at the second layer network to provide (G.805) links to the third layer
network, trails are set up at the third layer network to provide (G.805) links
to the forth layer network, etc. In this way the topology of each layer network
is created, and the transport network is ready to support user traffic.
So a part of the capacity of the transport network is "burned" inside the
transport network to provide for capacity in client layer networks within that
transport network. The remainder of the capacity in each of the layer networks
is to support user connections through the transport network.
This set up of trails supporting client layer links within the transport network
is typically done before any user traffic is routed over the network. It is
based on network planning with the goal to optimise the use of the transport
network and its resources.
To support PWE3 services, a specific fully meshed PWE3-PSN (sub)layer network is
to be created (within the boundaries of a general purpose MPLS layer network),
in which PSN-tunnels (which are MPLS (sub)layer network trails) support the
PWE3-PSN links (G.805 terminology). These PWE3-PSN links terminate in the PEs,
in which the individual PWE3-PSN link connections (i.e. the PWs) are connected
to PWE3-PSN trail termination functions (i.e. the MPLS VC termination points).
As layer network topology should typically not be changed on individual
connection requests, the PWE3-PSN (sub)layer network topology must connect a PE
to all other PEs before first user traffic is accepted (assumption is that more
than one user will be connected to a PE).
In a typical transport network in Europe with some 7500 offices to which users
connect, this implies about 28 million PWE3-PSN links (i.e. PSN-tunnels) are to
be set up. Most likely however this number can not be handled administratively,
and additional grooming points in the middle of the network are required. The
single-hop-PE-to-PE approach can be maintained when a hierarchy of PSN-tunnels
is deployed, or a multi-hop-PE-to-PE approach is to be introduced in which
PSN-tunnels (PWE3-PSN links) terminate at intermediate nodes (P) and MPLS VC
signals are cross connected/routed from an ingress PSN-tunnel to an egress
PSN-tunnel. The MPLS VC label will not longer be a fixed label however, as
translation is to be supported at those points.
This latter shouldn't impact the specific PWE3 work. PWE3 defines the
encapsulation/mapping methods, which should be independent of the transport of
this signal through the PSN.
Regards,
Maarten
Shahram Davari wrote:
>
> Sasha,
>
> > -----Original Message-----
> > From: Sasha Vainshtein [mailto:Sasha@axerra.com]
> > Sent: Wednesday, May 15, 2002 11:14 AM
> > To: 'Rutemiller, John'; 'pwe3@ietf.org'
> > Subject: RE: [PWE3] PWE3 question
> >
> >
> > John,
> > Thank you for a prompt response.
> > Please see some more comments inline.
> > Hopefully they will be useful.
> >
> > With best regards,
> > Sasha Vainshtein
> > email: sasha@axerra.com <mailto:sasha@axerra.com>
> > tel: +972-3-7659993 (office)
> > +972-8-9254948 (res.)
> > +972-58-674833 (cell.)
> >
> >
> >
> > > -----Original Message-----
> > > From: Rutemiller, John [mailto:John.Rutemiller@marconi.com]
> > > Sent: Wednesday, May 15, 2002 3:58 PM
> > > To: 'pwe3@ietf.org'
> > > Subject: RE: [PWE3] PWE3 question
> > >
> > >
> > > There are many ways to build a network.
> > >
> > > The virtual "network" you describe is one way, in which case
> > > the tunnel is not created explicitly for PW transport. But
> > > others may choose to create a tunnel explicitly for PW transport.
> > >
> > No problem with that. But, IMHO, there is a difference between
> > creating a tunnel to b used by a (still unknown) group of PWs
> > and creating a tunnel per PW.
> > In the 1st case, there is no casual connection between creation
> > of any specific PW and the state of P routers; in the 2nd one,
> > there would be.
>
> OK, how about this: I have my PSN and don't have any PW yet, but I
> expect to have N*PW (N is small) between to PEs. I could create
> N*LSP between the two PEs. Now After I receive a PW request, I choose
> one of the LSPs that best fits that PW.
>
> If no suitable LSP is found, then I either will change the attributes
> of that LSP (by signaling) or create a new LSP. This last part is no
> different in tunneled or non-tunneled solution, because even in case
> of tunneled solution, if the tunnel is not suitable you need to take
> exactly the same actions.
>
> > >
> > > In the later case, the tunnel is closely tied to the PW. No, the
> > > tunnel is not created in direct response to any PW stream.
> > >
> > IMHO this means that setup/teardown of PWs do not exert any
> > control over the state of P routers, so it's OK.
>
> What if all PWs are tear downed, do you still keep the tunnel?
> if so why?
>
> > >
> > > But it is still created directly for the PW service.
> > >
> > My English may be faulty, but I would say that the tunnel is
> > created to be used by the (multiple and currently non-existing) PWs,
> > not "for the (specific) PW service". If I install new
> > interface cards in
> > my
> > P routers and connect them over a new fiber with the intent to
> > use new capacity thus created for (yet non-existent) PWs,
> > these PWs still do not exert any control over my PSN!
>
> But PWs can't use those links either, unless you modify the
> FIBs on those routers.
>
> -Shahram
>
> > >
> > > Same goes with the choice of whether to use an E-LSP. Network
> > > design decision.
> > >
> > > Clearly, using a common LSP for all traffic between two nodes
> > > and using E-LSPs has certain scaling and restoration advantages
> > > (fewer restore faster for the entire network).
> > >
> > > But, some carriers may want to seperate the fate of the different
> > > traffic. For example, the carrier may want to restore PW services
> > > before voice services because the PW users pay more for the
> > bandwidth.
> > >
> > > John
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com]
> > > > Sent: Wednesday, May 15, 2002 10:11 AM
> > > > To: 'Rutemiller, John'
> > > > Cc: 'pwe3@ietf.org'
> > > > Subject: RE: [PWE3] PWE3 question
> > > >
> > > >
> > > > John,
> > > > Please see some comments/responses inline.
> > > > Hopefully they will clarify my position.
> > > > With best regards,
> > > > Sasha Vainshtein
> > > > email: sasha@axerra.com <mailto:sasha@axerra.com>
> > > > tel: +972-3-7659993 (office)
> > > > +972-8-9254948 (res.)
> > > > +972-58-674833 (cell.)
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Rutemiller, John [mailto:John.Rutemiller@marconi.com]
> > > > > Sent: Wednesday, May 15, 2002 12:12 PM
> > > > > To: 'pwe3@ietf.org'
> > > > > Subject: RE: [PWE3] PWE3 question
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com]
> > > > > > Sent: Friday, May 10, 2002 2:57 AM
> > > > > > To: 'Shahram Davari'
> > > > > > Cc: 'pwe3@ietf.org'; Danny McPherson (E-mail); 'Andrew G.
> > > > > > Malis'; Neil.
> > > > > > 2. Harrison (E-mail)
> > > > > > Subject: RE: [PWE3] PWE3 question
> > > > > >
> > > > > >
> > > > > > Shahram and all.
> > > > > > Please see a brief comment inline.
> > > > > >
> > > > > [SNIP]
> > > > > >
> > > > > > I would suggest a very simple criterion regarding exertion or
> > > > > > non-exertion of control over PSN: if setup/teradown of a PW
> > > > > > requires modification of the FIB in at least one PSN
> > node that
> > > > > > does not act as the PE for this PW, it means that
> > control over
> > > > > > this router has been exerted.
> > > > > >
> > > > > > This criterion does not depend on the protocol being used
> > > > > > (static,LDP, RSVP or else).
> > > > > >
> > > > > > The single-label model requires allocation of a new
> > label per PW
> > > > > > in each interior node on the path fromingress to
> > > egress, and hence
> > > > > > means exertion of control over the PSN unless the the pair of
> > > > > > PEs are adjacent (the "single hop" case mentioned by Neil).
> > > > > >
> > > > > > Can we agree on that?
> > > > > >
> > > > >
> > > > >
> > > > > Creation of a Pseudo wire requires a tunnel label.
> > > > >
> > > > Correct. You must associate every direction of a PW
> > > > over an MPLS network with an LSP leading from the
> > > > ingress PE (for this direction) to egress PE.
> > > > >
> > > > >The creation of this tunnel must be configured.
> > > > >
> > > > It can be created regardless of any specific PW that would use it.
> > > > And it could be created in many ways, including hop-by-hop
> > > forwarding
> > > > provided by the vanilla LDP.
> > > > Once created, such a tunnel can be used by - and, for scalability
> > > > reasons, SHOULD be used - by more than one PW between the
> > > > same pair of PEs.
> > > >
> > > > And it could be created in many ways, including "vanilla" LDP
> > > > in DU mode.
> > > > >
> > > > >The establishment of the tunnel will affect the FIB if the P
> > > > routers.
> > > > >
> > > > Correct. However, as I said above, creation of the tunnel
> > > (to be used
> > > > by multiple PWs) is not caused by creation of the PWs. Creation
> > > > of PWs using an already existing tunnel would not affect
> > FIB in the
> > > > P routers, only in PEs.
> > > > >
> > > > >Furthermore, the tunnel must be created with a forwarding class
> > > > >that is sufficient to carry the desired pseudo wire traffic.
> > > > >
> > > > There are many ways to associate a certain forwarding behavior
> > > > with the EXP bits across an LSP. E.g., one can use
> > > > Preconfigured EXP<-->PHB Mapping in LSPs that have been
> > > > created by LDP in DU mode.
> > > >
> > > > Such an method cannot be used if reservation of resources
> > > > must be associated with an LSP. But even then nothing
> > > > prevents creation of a "planned" network of DiffServ-enabled
> > > > LSPs with BW reservation beforehand regardless of any
> > > > specific PW, and then creation of PWs that use available
> > > > capaity on this "network".
> > > > >
> > > > > If traffic classes are to be separated (e.g, ATM CBR gets EF and
> > > > > ATM UBR gets best effort), then multiple tunnels must be created
> > > > > across the network.
> > > > >
> > > > Not necessarily. A single E-LSP will may support up to 8 different
> > > > traffic classes. And this can be done by using preconfigured
> > > > EXP<-->PHB mappings, too.
> > > > >
> > > > >
> > > > > Therefore, the PW has in some way exerted control over
> > > the P routers
> > > > > even with the tunnel creation.
> > > > >
> > > > This would only happen if you apply the "One PW = One
> > Tunnel" model
> > > > that originated this thread. And that is exactly why I said
> > > > that, IMHO,
> > > > this model is beyound the chartered PWE3 scope. The model that
> > > > separates creation of transport tunnels from creation of PWs is
> > > > within this scope.
> > > > >
> > > > > John
> > > > >
> > > > > _______________________________________________
> > > > > pwe3 mailing list
> > > > > pwe3@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/pwe3
> > > > >
> > > >
> > >
> > > _______________________________________________
> > > pwe3 mailing list
> > > pwe3@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/pwe3
> > >
> >
> > _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pwe3
> >
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
begin:vcard
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard