Subject: Re: PWE Service interworking

From: Mark Seery <[email-masked]>
Date: Tue, 3 Jun 2003 13:10:44 -0700 (PDT)

--- Eric Rosen <[email-masked]> wrote:
> 
> Mark> Before I attempt  to define service
> interworking, I  think it would be
> Mark> valuable   for   you  to   explain   the  
> different  purposes   these
> Mark> encapsulations have.  
> 
> All I  meant is that RFC  1483, e.g., defines an 
> encapsulation for carrying
> arbitrary  layer  2 or  layer  3  PDUs over  ATM, 
> whereas  PWE3 defines  an
> encapsulation  for carrying  layer 2  frames over  a
> pseudowire  over  IP or
> MPLS.   As the "gap"  between the  emulated service 
> and network  service is
> very different in  the two cases, it's not obvious
> what  one means by saying
> "why didn't  you use the  1483 encaps for 
> pseudowires"?  There was  also an
> expectation that a given pw would carry a single
> kind of payload. 

It is not that I specifically think 1483 should be
used for all traffic types, just noting that while
1490 and 1483 deal with different underlying
protocols, they are so similar as to be easily
interworked.

But thanks for the clarification, in my next post I
wil now do as you request and try to define service
interworking in such a way as we can all have a
constructive, and hopefully brief dialog on the issue.

Mark

---

From: Mark Seery <[email-masked]>
Date: Tue, 3 Jun 2003 14:00:59 -0700 (PDT)

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