Subject: Re: PWE Service interworking

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

So having tried a general description, a slightly 
(not constructing access points etc.) treatment of
this issue might look something like the following.

Acronyms NIWF - network internetworking function and
SIWF - Service interworking function are not acronyms
used by any standards body (that I know of).

fig.1 is essentially how I think of PW today.

Network Interworking
====================
fig.1

 CE1         PE1         P         PE2       CE2
        -----------            -----------
        |   NIWF  |            |  NIWF   |  
------  |---------|   ------   |---------|  ------
| FR |--| FR | PW |---| PW |---| PW | FR |--| FR |
------  -----------   ------   -----------  ------

Where FR could be FR, Ethernet, or ATM.
In the ATM case, AAL5 would (typically) be
encapsulated on to a PW, and no understanding of upper
layer protocols would be required.

Service Interworking
====================
fig.2

 CE1         PE1         P         PE2       CE2
        -----------            -----------
        |   SIWF  |            |         |  
------  |---------|   ------   |         |  ------
| FR |--| FR | PW |---| PW |---|   PW    |--| PW |
------  -----------   ------   -----------  ------

The scenario of a PW going to a CE is unlikely today,
of course, but shown here as a theoretical option.

or
fig.3

 CE1         PE1         P         PE2       CE2
        -----------            -----------
        |   SIWF  |            |         |  
------  |---------|   ------   |         |  ------
| FR |--| FR | MP |---| MP |---|   MP    |--| MP |
------  -----------   ------   -----------  ------

The scenario of a MPLS (MP) service going to a CE is
more likely than that of a PW, but still not likely to
be widespread in the near term

or
fig.4

 CE1         PE1         P         PE2             CE2
        -----------            -----------------
        |   NIWF  |            |  NIWF | SIWF  | 
------  |---------|   ------   |---------------| 
-----
| FR |--| FR | PW |---| PW |---| PW | FR | ATM
|--|ATM|
------  -----------   ------   ----------------- 
-----

In this scenario FR is encapsulated on to a PW at PE1
and decapsulated off of a PW at PE2 and then service
interworked to an ATM service. The ATM service may be
going to a CE or to an ATM network (in which case the
SIWF would be slightly different)

or
fig.5

 CE1         PE1         P         PE2       CE2
        -----------            -----------
        |   SIWF  |            |  SIWF   |  
------  |---------|   ------   |---------|  ------
| FR |--| FR | PW |---| PW |---| PW | ATM|--| ATM|
------  -----------   ------   -----------  ------

this seems simpler than some of the previous examples
but might actually be quite hard and is where
translation to from PW encaps would need to be pretty
good (my guess).

or
fig.6

 CE1       FR SW      ATM SW        PE1         P
        -----------             -----------
        |   SIWF  |             |NIWF/SIWF|  
------  |---------|   -------   | --------|  ------
| FR |--| FR | ATM|---| ATM |---| ATM | MP|--| MP |
------  -----------   -------   -----------  ------

In this case FR is interworked with ATM, and RFC 1490
with RFC 1483 at the FR SW. Then at the PE, ATM is
network or service interworked with MP. In the case of
routed RFC 1490/1483, an IP packet could be popped and
encapsulated over MPLS, but there would still be OAM
interworking between the ATM and MPLS functions. 

In the case of bridged RFC1490/1483, it may be
possibly to interwork the ATM and MPLS functions and
then interwork RFC1483 and PW.

Just some ideas of scenarios we may be looking at in
the future.

Having thought about it, there is probably no getting
by with just a casual discussion of this issue. So we
either add it to the charter now, or delay it as seems
to be the consensus (i.e. I have only heard one strong
voice pushing it to the forefront).

Mark

---

From: Eric Rosen <[email-masked]>
Date: Wed, 04 Jun 2003 12:41:26 -0400

Mark> Service  interworking -  ingress  and egress  attachment circuits  use
Mark> different protocols 

That's clear enough. 

My  assumption has  always  been  that the  interworking  function would  be
applied either  before or after  the use of  the pseudowire.  When  there is
already  a well-defined service  interworking function,  as in  ATM/FR case,
that function  would be used.  Hence  the fact that  service interworking is
taking place is transparent to the  pseudowire, and no PWE3 (or IETF) issues
are raised. 

I think this is the same as you indicate in your example:

     CE--FR--PE--FR/PW/PSN--PE-IWF-ATM-CE

Is there anything more to say about it?

In  the special  case where  the  payload is  always IP  datagrams, but  the
ingress  and  egress  ACs  use  different data  link  protocols,  then  "ARP
Mediation" can  be used  for interworking, as  long as  there is no  need to
provide any sort of faithful data  link emulation.  This seems to be the one
case that might be of interest to the IETF.