Re: [PWE3] PWE Service interworking

[Mark Seery <mark@mseery.com>]

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


_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3