RE: [PWE3] PWE Service interworking

[Shahram Davari <Shahram_Davari@pmc-sierra.com>]

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