[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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