[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [PWE3] PWE Service interworking
I am participating in this effort in all three groups (IETF, MPLS and MEF).
IETF showed the door for service interworking (i.e. not a charter :-),
although this may change and I believe IP-inteworking PW type already
defined?
MPLS forum is tackling service interworking when disparate
ACs are connected through MPLS PW.
MEF is concentrating on service interworking when disparate
ACs are directly attached.
Both MPLS forum and MEF are going to concentrate first
on service interworking for protocols that would work - such as IP.
For multiprotocol, some assumptions are made. Such as
CEs would treat the underlying FR/ATM transport as Ethernet
and generate bridged Ethernet frames over that transport.
As for "service" aspects of the interworking, details are being hammered
out; Ethernet-LMI of MEF would help.
At MPLS forum, what frame format to use over the service interworking
PW is being discussed; canonical format of ATM SDU is one of the
option.
Again, at both forums this work is in infancy but charter exist.
/himanshu
wavesmith networks
> -----Original Message-----
> From: Jack Pugaczewski [mailto:jtpugac@qwest.com]
> Sent: Wednesday, June 04, 2003 11:53 AM
> To: Sasha Vainshtein; 'Shahram Davari'; 'Mark Seery'
> Cc: pwe3@ietf.org
> Subject: RE: [PWE3] PWE Service interworking
>
>
> Then what group/organization is going to take on the
> interworking and all of
> the issues ?
>
> PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY
>
>
>
> > -----Original Message-----
> > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On
> Behalf Of Sasha
> > Vainshtein
> > Sent: Wednesday, June 04, 2003 11:28 AM
> > To: 'Shahram Davari'; 'Mark Seery'
> > Cc: pwe3@ietf.org
> > Subject: RE: [PWE3] PWE Service interworking
> >
> >
> > Shahram, Mark and all,
> > A couple of comments/questions.
> >
> > 1. I agree with Shahram that the model he has proposed
> > is much simpler than one proposed by Mark in his
> > "explanation email". To me, this makes it preferable.
> >
> > 2. My gut feeling is that:
> > a) This difference in approaches is exactly what
> > the current PWE3 WG Charter defines as the
> > rationale for the PWE3 work when it says:
> > <quote>
> > The PSN can transport PDUs for multiple services,
> > and the conversion/interworking functions per
> > service pair are not needed.
> > <end quote>
> > b) It means (and has been correctly interpreted by many
> > people including, I think, Mark) that the Charter defines
> > "service interworking" out of scope for PWE3 - and for a good
> > reason.
> >
> > 3. I am not sure if the term "X-to-MPLS service interworking"
> > is applicable to Shahram's diagram. E.g., for PL=Ethernet I
> > do not expect that the EXC bits in the MPLS encap will reflect
> > DE/CLP markings of the containing FR/ATM-based AC. All the
> > ETHoATM/ETHoFR-specific information will be simply discarded
> > by the PEs!
> > (At least this is, IMO, what the current Ethernet encapsulation
> > draft says:-). However, this does not affect the
> conclusions of (1)
> > and (2) above in any way.
> >
> > Did I miss something?
> >
> > 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: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> > > Sent: Wednesday, June 04, 2003 4:42 PM
> > > To: 'Mark Seery'; pwe3@ietf.org
> > > Subject: RE: [PWE3] PWE Service interworking
> > >
> > >
> > > Mark,
> > >
> > > Regarding Service interworking I believe the simplest and
> > > most logical model is to do service interworking with MPLS
> > > on both IWFs. Assuming (PL= Payload), the following
> figure shows an
> > > example of what I think is a proper AT-MPLS-FR service
> interworking:
> > >
> > >
> > > CE--------PE-------P--------PE---------CE
> > > PL PL PL PL
> > > AAL5 X X Q.922
> > > ATM MPLS MPLS FR
> > >
> > > Both PEs do service interworking. One does ATM-MPLS service
> > > interworking and the other one does FR-MPLS service interworking.
> > >
> > > The advantage is that each PE needs to support a maximum
> of N service
> > > interworking functions (N is all known L2 protocols). While your
> > > proposed model requires N square service interworking
> functions to be
> > > supported in a single PE.
> > >
> > > Yours,
> > > -Shahram
> > >
> > >
> > > >-----Original Message-----
> > > >From: Mark Seery [mailto:mark@mseery.com]
> > > >Sent: Tuesday, June 03, 2003 5:01 PM
> > > >To: pwe3@ietf.org
> > > >Subject: Re: [PWE3] PWE Service interworking
> > > >
> > > >
> > > >All, remember the constraints: a) can't quote from a
> > > >non-IETF standard, b) can't use the word layer. Will
> > > >do my best.
> > > >
> > > >Defining service interworking
> > > >=====================
> > > >
> > > >The simplest explanations (IMO) for interworking are
> > > >as follows:
> > > >
> > > >Network interworking - ingress and egress attachment
> > > >circuits use the same protocols
> > > >Service interworking - ingress and egress attachment
> > > >circuits use different protocols
> > > >
> > > >Now any interworking agreement is going to specify
> > > >exactly what protocols, so the actual definition
> > > >necessarily becomes less generalized. Typical
> > > >protocols that have been involved in interworking
> > > >standards are link-layer PDUs and adaptation layers
> > > >(FR, ATM, AAL1, AAL5) and Multiprotocol encapsulation
> > > >standards (RFC 1483, RFC 1490).
> > > >
> > > >Simplistically a network interworking function has to
> > > >map a service PDU to an encapsulation that provides
> > > >service attributes on an underlying network such that
> > > >the service entrities at each side of the network do
> > > >not realize they are not operating over a native
> > > >service network. An example of this would be two Frame
> > > >Relay attachment circuits connected to an ATM network,
> > > >or two Ethernet attachment circuits connected to a
> > > >MPLS or IP network (i.e. PW)
> > > >
> > > >For example:
> > > >
> > > >CE--FR--PE--FR/PW/PSN--PE-FR-CE
> > > >
> > > >I don't think there has been much controversy about
> > > >this, the only real area of controversy I recall is
> > > >the degree to which the PW/PSN emualtes the
> > > >ingress/egress service definitions. In providing this
> > > >service emulation things such as the following may be
> > > >mapped:
> > > >
> > > >1. Variable length PDU formatting and delimiting
> > > >2. Error detection
> > > >3. Connection multiplexing
> > > >4. Loss Priority Indication
> > > >5. Congestion Indication (Forward and Backward)
> > > >6. PVC Status Management
> > > >
> > > >So in this sense Eric is correct. RFC 1490/1483 are
> > > >not the same as the encapsulations used to perform
> > > >network interworking, or what might otherwise be
> > > >referred to as (sub)convergence. In this context the
> > > >more appropriate question might be, was AAL1 or AAL5
> > > >explored as to their applicability for encapsulating
> > > >services over MPLS or IP; they may not provide what is
> > > >needed, and that is a perfectly acceptable answer if
> > > >that is the case.
> > > >
> > > >Some standards differentiate between the case when two
> > > >subscribers are communicating over a cloud, and when
> > > >two networks are communicating over a third cloud; I
> > > >will not for the sake of trying to establish some
> > > >basic concepts.
> > > >
> > > >Now we move to service interworking, where we are
> > > >trying to provide for a service to have two different
> > > >interfaces at either end of a cloud. In this case,
> > > >simple encapsulation does not work, the hard task (and
> > > >I do understand it is not considered trivial by some
> > > >developers) is to have say Frame Relay go in one side,
> > > >and have ATM come out the other side. For example:
> > > >
> > > >CE--FR--PE--FR/PW/PSN--PE-IWF-ATM-CE
> > > >
> > > >The IWF (interworking function) could be in a variety
> > > >of places, I just put it there for grins.
> > > >
> > > >In this example, we now have to not only convert the
> > > >Frame Relay base protocol to ATM, but if we do not
> > > >convert RFC1490 running above it to RFC1483, then
> > > >there will be problems at that level of protocol
> > > >interaction.
> > > >
> > > >NLPIDs are used often in encapsulations to provide
> > > >indication of encapsulated protocols. Service
> > > >interworking could be done at the ingress PE, in which
> > > >case the resultant PW is really in the format of the
> > > >egress attachment circuit. Another option is to do it
> > > >at the egress PE, which would mean translating from
> > > >the 1490/FR/PW/MPLS or IP PDUs to the resultant
> > > >1483/aal5/atm attachment circuit. The question then
> > > >becomes should the FR PDU just be popped from the PW
> > > >and examined, or should the PW indicate, by a NLPID
> > > >equivalent, what is contained within the FR PDU? That
> > > >would probably be an implementation decision, but
> > > >those types of dicussions may uncover any weaknesses
> > > >in the current methods, if they exist at all, and they
> > > >may not.
> > > >
> > > >If the PW is discarded before the IWF function, then
> > > >that is probably not a problem as long as the
> > > >resultant FR PDU is sufficient to perform the mapping;
> > > >and therefore I am not concerned that the PW
> > > >"whatever" disappears, this is analgous to the ATM
> > > >AAL5 PDU disappearing and a new one being created, if
> > > >the service interworking was performed in the same way
> > > >
> > > >So the more I think about, the less problems I
> > > >see..........
> > > >
> > > >There is some thought floating around that if the PW
> > > >encap was similar to or identical to whatever network
> > > >is most likely to be interworked to, then that may
> > > >make like easier for implementors and operators - that
> > > >I leave as a discussion point, and note the horse has
> > > >probably already bolted on that one, for this WG, in
> > > >this time slot.
> > > >
> > > >Mark
> > > >_______________________________________________
> > > >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
>
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3