Re: [PWE3] [mpls-tp] MPLS vs MPLS-TP (changed subject)

[[e-mail]]

Neil
 thank you for your explaining in detail. according to my understanding. 
is it unnecessary for co-ps network to have source label and PID label 
information in the traffic unit?  packet forwarding is only depend on 
destination label in traffic unit? eg. if a etherent service need to be 
transported by MPLS-TP LSP, it may transport the etherenet service to 
far-end PE of LSP. it is the key problem to distinguish which service the 
packet will belong to in the far-end PE if no pw label informations.

maybe my uderstanding be true?

best regards
liu







<[e-mail]> 
2009-08-29 17:32

收件人
<[e-mail]>
抄送
<[e-mail]>, <[e-mail]>, 
<[e-mail]>, <[e-mail]>, <[e-mail]>, 
<[e-mail]>, <[e-mail]>
主题
RE: [PWE3] [mpls-tp]   MPLS vs MPLS-TP (changed subject)






Hi Liu...A more definitive explanation of how the 3 network modes arise, 
and what the consequences are for labelling in them, can be found in G.800 
(largely written by my colleague Andy Reid).   I've written a (hopefully 
easier to read than G.800) internal paper on this topic, which also looks 
at a more optimal architecture where the 3 modes work in concert, which I 
could send you, but see if this description helps:
 
Note - There is more to networking that just labelling 
considerations....in particular one needs to understand how resource 
assignment works in each of the 3 modes and why, for example, a connection 
can only have a single-source.  This is all addressed in G.800.
 
All the 3 network modes that use directed routing (see Note) use 
destination forwarding, ie some label that points towards the sink point 
of the connection (co) or flow (cl).
 
Note - Original Ethernet does not use directed forwarding.  It uses a 
'broadcast at source filter at sink approach' (at least before SAs are 
learnt in the DP).  Further, the addresses here are not topologically 
significant, ie they don't tell one where an address is, so the addresses 
here are actually names..  The first step to make any network mode 
scalable is to use addresses that are related to topology/location (but 
see Aside below) and some process for route calculation (which can be 
centralised or distributed).  Aside=> Although one should make addresses 
related to topology (for aggregation purposes) they should not be totally 
bound to topology.....if they are then one needs to change the addressing 
structure with any change in topology.
 
We usually do not take any source labels into account when forwarding (any 
mode).
 
The cl-ps mode does not create any transport constructs before it sends 
traffic units.  This means each traffic unit must contain all the 
information that is required.  And key here is an absolute DA, an absolute 
SA and a client payload PID....these can all be a called labels, ie DA 
label, SA label, PID label, in general sense.
 
The co-cs mode can apply to time, freq (eg lambda) and space (eg fibre) 
resource dimensions.  The time dimension of resource is of most interest. 
The co-cs mode uses regular time-slices.  Each time slice has a 
fixed/known start epoch (this is the forwarding DA-proxy label) and 
(crucially) duration.....it is both these point that makes the co-cs mode 
fully resource deterministic at all scales....the former point allows the 
network to be treated as a synchronous state machine, whilst the latter 
point simply assigns a known/fixed resource to a client at all points in 
the network.  We do not need to add a SA label to the co-cs mode traffic 
units (time-slots) because the parent transport connection we create can 
only have a single source.....indeed, this single source property cannot 
be violated in the co-cs mode because of the 2 previous points that 
coupled labelling and resource assignment.  We also do not need to add a 
PID field providing the client is consistently the same.  {Aside=> If one 
does want to add a PID field one can do so with GFP which is a ngeneric 
adaptation function initially designed for the co-cs mode.  GFP provides 
other adaptation properties, like client traffic unit delineation and 
error checking.  Ethernet can also use GFP adaptation (eg for PBB-TE type 
of Ethernet where the Ethertype 0x801F has been assigned for this 
purpose.}
 
The co-ps mode can only apply to the time-dimension.  Here the time 
resource is carved-up using irregular time-slices.  This means both start 
epoch and duration (ie actual resource used) are decoupled actions. 
Further, neither may be fixed/known in advance.....this is why more care 
has to be exercised here if one wants to have good control over resource 
allocation (ergo performance SLAs to clients).  One consequence of this is 
that we must add an explicit forwarding DA-proxy label to each co-ps 
traffic unit.  If we respect the requirement of a connection (ie single 
source)....which is critical for resource management considerations.....we 
can omit a SA label.  Similarly, if we only carry a single client we can 
omit a PID label (we could however add a PID, like the one found in GFP 
say and as used by the co-ps mode, should we require that a single/same 
connection carries different clients).  In other words, in the co-ps mode 
we require that the (parent) connection construct we create carries SA 
label and (usually) PID label information and thus these do not need to be 
carried by the (child) traffic units.
 
We can also take a further short-cut on the DA forwarding label if 
required.  The forwarding label must be larger enough in code-space to 
distinguish the largest number of clients that can appear a single link 
connection (=hop), noting that this link connection in layer N is provided 
by an end-end network connection at layer N-1.  This leads to the 
well-known forwarding paradigm of 'label-swapping' and it has been used by 
FR, ATM and MPLS.  However, there are distinct advantages (esp wrt to OAM 
considerations) to not swapping forwarding labels and  adding an absolute 
SA label to child traffic units.  This is how PBB-TE works, and it arises 
because the original cl-ps Ethernet traffic unit, which has absolute SA/DA 
labels because of its cl-ps mode origin, is re-used in PBB-TE (though 
PBB-TE and native cl-ps Ethernet form quite distinct/different layer 
networks even though they share an identical traffic unit).  One 
consequence of this is that such a network is self-protecting against 
misconnectivity defects without running any OAM at all.
 
Does that help Liu? 
 
regards, Neil

From: [e-mail] [mailto:[e-mail]] 
Sent: 29 August 2009 07:30
To: Harrison,N,Neil,DEY2 R
Cc: [e-mail]; [e-mail]; 
[e-mail]; [e-mail]; [e-mail]; 
[e-mail]; [e-mail]
Subject: Re: [PWE3] [mpls-tp] MPLS vs MPLS-TP (changed subject)


Neil 
maybe what you said be too abstract to not completely your meaning. IMO, I 
haven't heard of the two concept of "source forwarding label" and " 
destination forwarding label" in co-ps network. 
IMO, Each node will depend on local LSP identifier or globe LSP identifier 
 to transport traffic packet in co-ps network. eg. PBT-TE ,each  packet 
for ESP will depend on ESP Identiifer( VLAN+Destination MAC) field on 
traffic unit. while for T-MPLS/MPLS/MPLS-TP , Since each node transporting 
traffic packet is based on local label. but local label must include the 
information of LSP identifier secretely. 

can you clarify it.thank you. 

best regards 
liu






<[e-mail]> 
发件人:  [e-mail] 
2009-08-28 20:46 


收件人
<[e-mail]>, <[e-mail]>, 
<[e-mail]>, <[e-mail]> 
抄送
[e-mail], [e-mail] 
主题
Re: [PWE3] [mpls-tp]   MPLS vs MPLS-TP (changed subject)








Thanks Yaunlong...my responsese are in-line: 

> -----Original Message-----
> From: Jiang Yuan-long [mailto:[e-mail]] 
> Sent: 28 August 2009 03:06
> To: Harrison,N,Neil,DEY2 R; [e-mail]; 
> [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [mpls-tp] [PWE3] MPLS vs MPLS-TP (changed subject)
> 
> Hi Neil,
> 
> Please see my comments inline.
> 
>   Best regards
> Yuanlong Jiang
> 
> ----- Original Message ----- 
> From: <[e-mail]>
> To: <[e-mail]>; <[e-mail]>; 
> <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>
> Sent: Thursday, August 27, 2009 9:45 PM
> Subject: Re: [mpls-tp] [PWE3] MPLS vs MPLS-TP (changed subject)
> 
> 
> > Thanks Matthew..please see my further remarks in-line.
> >
> >> -----Original Message-----
> >> From: BOCCI Matthew [mailto:[e-mail]]
> >> Sent: 27 August 2009 13:31
> >> To: Harrison,N,Neil,DEY2 R; [e-mail];
> >> [e-mail]
> >> Cc: [e-mail]; [e-mail]; [e-mail]
> >> Subject: RE: [mpls-tp] [PWE3] MPLS vs MPLS-TP (changed subject)
> >>
> >> Hi Neil,
> >>
> >> > -----Original Message-----
> >> > From: [e-mail] [mailto:[e-mail]]
> >> > Sent: 27 August 2009 08:40
> >> > To: BOCCI Matthew; [e-mail]; [e-mail]
> >> > Cc: [e-mail]; [e-mail]; [e-mail]
> >> > Subject: RE: [mpls-tp] [PWE3] MPLS vs MPLS-TP (changed subject)
> >> >
> >> > Hi Matthew....I have some questions for you...snipped to topic
> >> in-line:
> >> >
> >> > Matthew wrote in response to Igor 26 August 2009 17:59
> >> > >
> >> > > However, there are those of us who also want to 
> deliver L2 and L3
> >> > > services from PEs and carry them over MPLS-TP LSPs. The PWs
> >> supporting
> >> > > some of those services use LDP, and it would also be useful to
> >> inherit
> >> > > the OAM used for the underlying LSPs on those PWs.
> >> >
> >> > NH=> There are several things that are getting mixed-up 
> here.  And I
> >> > think we do need a technical discussion on these points 
> to get some
> >> > general clarity across the community.
> >> >
> >> > Firstly, in MPLS-TP there should never be a PW layer 
> network above
> >> > MPLS-TP.  I hope the reasons for this are clear, ie I 
> can't see how
> >> > anyone can claim MPLS-TP is providing a transpport network
> >> function if
> >> a
> >> > consequence of this is that its spawns another co-ps 
> mode PW layer
> >> > network above it.  Do you agree with that view?
> >>
> >> You are assuming that MPLS-TP only encompasses the LSP tunnel
> >> hierarchy
> >> below the PW.
> >
> > NH=> Sort-of, but the key point here is that if we create a 
> transport
> > network (any) then I'm struggling to see why this should generate
> > another layer network above it.  PWs arose because of 
> LDP....we simply
> > had to add a new labelled header here to recover the lost source
> > information due to the LDP server.  But we don't have LDP 
> in MPLS-TP.
> > In fact had we used RSVP-TE instead of LDP we would not 
> have needed to
> > add a PW label to carry a single client....no other co-ps 
> server (and
> > for sure no co-cs server) technology requires this. A SS-PW 
> is one thing
> > (ie adaptation) but a MS-PW is a full-blown co-ps mode 
> layer network.
> > Should we really be allowing this *above* MPLS-TP that is 
> supposed to be
> > a transport network?
> 
> [J]  But if there are multiple clients between two PEs, you 
> must provide an 
> LSP for
> each of them without PW label as demultiplexer. I am afraid 
> it may not be a
> scalable scheme.

NH=> I'm not following you here.  There is nothing to stop one muxing
lots of different higher clients *within* an LSP of the client MPLS
layer stack and carried by a single server layer MPLS LSP.  This is
normal hierarchy construction, ie LSP link connection at layer N (which
can encompasss many different layer N LSP instances) = server LSP trail
at layer N-1.

Aside=> What limits this in practice is how much of the server layer
resource is available.  Noting that this resource is *inherited* in a
recursive manner right down to the duct, ie one cannot provide more
resource to clients (at all higher levels) than the limit of the
physical resource at the very bottom of the stack, ie where we modulate
an EM wave.

If not clear what I mean by this, think of a co-cs case of a E1 single
connection carrying multiple 64k link connections (rememeber a link
connection (ie 1-hop) in client layer N network = end-end network
connection in server layer N-1 network (this can be an arbitrary no. of
hops in layer N-1)).  Now the co-cs mode *couples* labelling and
resource assignment (which is one reason its always been, and always
will be, the de facto transport network type at the very
bottom-of-stack).....time-slot start epoch = forwarding label, timeslot
*duration* = resource allocation.  Thus, in this example we can have a
max of 31 64k client link connections of a E1 trail....this is
determined by how the resource is carved up here, ie based on regular
time-slices in the co-cs mode time dimension.

When we deal with the co-ps mode labelling and resource allocation are
*not* coupled actions...further, the forwarding label MUST be explicit
in the traffic unit and its start/duration is based on a variable
epoch/time-slice.  If we respect the single source rules of a connection
we can omit a source label from the traffic unit.  If we only carry a
single client we can omit a PID label from the traffic unit.  Further,
we only need to make the destination fowarding label big enough to cater
for the max number of client N link connections we want to have on a
single hop of the N-1 server (ie this is proper muxing)....in other
words we can reduce the resolution of the fowarding label to link-unique
rather than network unique and use label-swapping (this has some OAM
operational disadvantanges however). 

Aside=> in the cl-ps mode the DA, SA must always be network
unique/present and a PID label must always be present....as there is no
connection to carry this information.

So when we are dealing with the co-ps mode we must pay particular
attention to resource allocation as well as labelling ...the co-cs mode
does all this for us as I noted above.
> 
> >
> > Not sure if you recall the early days of GFP, but some 
> folks wanted to
> > start adding functionally and making this multi-hop (ie a switched
> > entity).  This would have defeated the original generic 
> adaptation role
> > that GFP was designed to address, ie GFP would have become 
> just another
> > layer network and we would have only suceeded in chasing the (still
> > required) generic adaptation function up another level. 
> IMO PWs should
> > be all about generic adaptation of clients, not the 
> creation of another
> > co-ps mode layer network above MPLS/MPLS-TP.  I would have 
> assumed this
> > would be obvious/agreeable.
> >
> 
> [J] As I know, there is already an ITU-T Rec (Y.1418) 
> focusing on the PW
> layer network.  It also provides a generic adaption layer, i.e.,  PW.

NH=> One cannot always stop people doing wrong things.  The fact that a
PW layer has been created is now a fact.  I did try and warn folks not
to go here over many years.  But what we should do now is understand
this and not replicate this error in MPLS-TP.  IMO that would be
unforgivable as there is no appeal to 'I did not understand that' now.

regards, neil
> 
> >> Well, my question to you is where do you believe the
> >> transport function providing the packet transport service 
> exists? i.e.
> >> at what (sub-)layer in the MPLS stack?
> >
> > NH=> This is an excellent question because it requires one to think
> > about what sublayering via a digital wrapper approach really
> > means....the S bit issue.  It's my personal view that 
> arbitrary nesting
> > is really not required in a transport network....each 
> 'level' should be
> > its own layer network.  If I look at the MPLS headers it's 
> really only
> > the bottom/outer one that has a fowarding (==transport) 
> semantic.  The
> > others (higher level) labels are used to carry other 
> semantics, eg an IP
> > VPN (rfc4364) BGP4 issued label can identify a VRF of a 
> specific client
> > VPN, a PW label must carry a source semantic to recover the 
> loss of this
> > information due to any lower level LDP merging (indeed you would not
> > require such a label if (i) the client is cl-ps like IP, 
> since a cl-ps
> > traffic unit has an absolute SA and recover the lost 
> merging information
> > itself) or (ii) the client was carried over a RSVP-TE server LSP
> > connection say).
> >
> 
> > In addressing your question one might also make the 
> observation that a
> > transport network should have the ability to 'put bits on 
> the wire', ie
> > have a physical interface specification.  Indeed, we must 
> always have a
> > real bottom-of-stack transport network that can modulate an 
> EM wave else
> > information cannot travel over geographic distance.  So 
> this raises an
> > interesting question of whether MPLS-TP should be called a 
> 'transport
> > network' at all....as it still requires a real transport network
> > underneath it.
> >
> >>
> >> If you are providing a transport service to e.g. Ethernet, 
> ATM, FR etc
> >> then the IETF specified way to do that in an MPLS network 
> is to use a
> >> PW.
> >>
> >> >
> >> > Secondly, a consequnce of the above observation is that 
> the PW needs
> >> to
> >> > revert back to an adaptation role (whether one considers
> >> the CW useful
> >> > adaptation or not is a secondary consideration, the key
> >> point is that
> >> > this must not become a networked entity).  Do you agree with this
> >> > consequence?
> >>
> >> Nothing is forcing you to use MS-PWs.
> >
> 
> [J] Here I agree with Mattew, MS-PW is just an option.
> 
> > NH=> Understood, but that is not the point. The real issue 
> here is what
> > do MS-PWs represent?...and I think its fairly obvious (at least to
> > anyone who comes at this with a func arch background) that they must
> > represent a layer network, ie they have become a switched entity by
> > definition of being multi-hop.  And if they do represent a layer
> > network:
> > - their labels need to change context and have a fowarding
> > semantic (and not a source semantic as the case if underlaid with a
> > merging LDP LSP that loses source information)
> > - in my mind at least it questions just what MPLS-TP is really
> > doing if it generates another co-ps mode layer network above
> > it.....where is the generic adaptation now gone to?
> >
> >> As you know, MS-PWs are only a
> >> deployment choice in order to address some requirements 
> that are well
> >> documented in RFC5254. In both SS-PWs and MS-PWs, the PW 
> is playing an
> >> adaptation role, but even in the SS-PW case it does more than that
> >> because it includes a multiplexing function.
> >
> > NH=> Yes I know it is protrayed like that (ie a muxing 
> function) but let
> > me ask you to consider this.  Suppose you just carried a 
> single client
> > from A to Z over a server LDP network.  How would determine where it
> > came from when it gets to Z?  Unless the client was cl-ps 
> like IP, you
> > would have no way to recover this information when you 
> removed the LDP
> > forwarding header at Z => ergo you must add a PW label that carries
> > source information.  This point is taken for granted in all 
> other co-ps
> > mode technologies that only use proper single source 
> connections, ie the
> > connection itself carries the source information, and that 
> is why we can
> > take a short-cuts in labelling and omit a SA label in a co-ps mode
> > traffic unit.  And of course one would not require a PW label if you
> > carried a single client over an RSVP-TE server LSP.
> >>
> >> >
> >> > Thirdly, one wants generic OAM that is associated with the trail
> >> > termination points of MPLS-TPs and is independent of which
> >> > service/client they are carrying, and it also allows one 
> to monitor
> >> > protection LSPs that are not currently carrying any client
> >> (ie waiting
> >> > to be invoked when needed).  Do you agree with this view?
> >>
> >> Yes, and indeed generic OAM that can operate at all of the
> >> levels in the
> >> MPLS network is exactly what MPLS-TP aims to provide.
> >>
> >> >
> >> > The conclusion here is that the OAM is associated with 
> the MPLS-TP
> >> > (trail termination function) and not the PW adaptation 
> function.  An
> >> > important corollary of this is that if any MPLS-TP LSPs suffer
> >> > misconnectivity then we should have consistent OAM on them
> >> (irrespective
> >> > of client use-case, eg IP-VPN, PW) so that the 
> detection/handling of
> >> the
> >> > defect is done consistently.
> >>
> >> OAM is necessary in the PW adaptation function, even in the
> >> SS-PW case,
> >> precisely because of the multiplexing function provided by
> >> the PW label.
> >
> > NH=> Let's go back to the case of carrying a single client over a
> > RSVP-TP LSP that respect the rules of a connection, ie single
> > source....you do not require a PW label here, and the OAM would be
> > associated with the RSVP-TP trail term points.  But I would most
> > certainly agree that in the case of MS-PWs (even if carried 
> over RSVP-TE
> > LSPs, ie a different server RSVP-TE LSP per hop of the 
> MS-PW client) you
> > do need an OAM function because there is no longer a 
> congruent span of
> > binding between the client and its server...indeed the 
> client is its own
> > layer network now and thus neewds its own OAM.
> >
> >> OAM can assure the binding of a PW instance to the service that it
> >> provides. This is no different from LSP OAM in the case of IP
> >> over MPLS.
> >
> > NH=> Indeed so...IP is here most definitely its own layer 
> network, and
> > IP requires its own OAM that is not associated with the 
> server...which
> > might be SDH VC4 or Ethernet say.
> >
> >> As mentioned above, the same MPLS-TP OAM will be 
> applicable whether we
> >> are talking about an LSP or a PW.
> >
> > NH=> Well, in the case of MS-PWs I can understand this. But 
> I struggle
> > to see why we need MS-PWs in MPLS-TP *if* MPLS-TP is 
> supposed to be a
> > transport network.
> >
> >
> > regards, Neil
> >>
> >> Regards
> >>
> >> Matthew
> >>
> >> >
> >> > As I also noted in an earlier mail (in response to 
> Stewart), it will
> >> > also be important for the CP (or MP) that sets-up/tears-down the
> >> MPLS-TP
> >> > LSP to (i) inform the LSP sink(s) of the expected SA in 
> any CV OAM
> >> pkts
> >> > and (ii) activate/deactivate the OAM in sync with LSP
> >> set-up/tear-down
> >> > actions (I think this is obvious from operational/service
> >> > considerations).  Do you agree with this requirement?
> >> >
> >> > > Such MPLS PWs are
> >> > > inherent in supporting these packet transport services,
> >> and must be
> >> > > managed as such. Therefore, they form a part of the overall
> >> > > architecture
> >> > > for MPLS-TP.
> >> > NH=> Well, they can only become the generic adaptation
> >> function in the
> >> > MPLS-TP architecture IMO.
> >> >
> >> > regards, Neil
> >> > >
> >> > > That said, it is true that we have not explicitly described a P
> >> router
> >> > > in the MPLS-TP Framework draft. Would it help if we 
> did this and
> >> > > detailed this and explained more clearly the elements of
> >> the profile
> >> > > that are required for this?
> >> > >
> >> > > Matthew
> >> > >
> >> > >
> >> > > >
> >> > > > Igor
> >> > > >
> >> > > > Stewart
> >> > > > _______________________________________________
> >> > > > mpls-tp mailing list
> >> > > > [e-mail]
> >> > > > https://www.ietf.org/mailman/listinfo/mpls-tp
> >> > > _______________________________________________
> >> > > mpls-tp mailing list
> >> > > [e-mail]
> >> > > https://www.ietf.org/mailman/listinfo/mpls-tp
> >> > >
> >>
> > _______________________________________________
> > mpls-tp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls-tp 
> 
> 
_______________________________________________
pwe3 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pwe3



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.




--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.