[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [PWE3] PWE Service interworking
Agreed Shahram.....using MPLS as a common core reduces the SIWF function
from N^2/2 to N dimension.
regards, Neil
> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> Sent: 04 June 2003 15:42
> 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