Subject: Re: Virtual ATM Networks over IP/MPLS(draft-ietf-pwe3-atm-encap-01.txt)

From: Raj Sarkar <[email-masked]>
Date: Fri, 27 Jun 2003 11:16:05 -0700

Hi Mustapha/Mathew,

I saw the document and the explicit model of network interworking
between ATM and MPLS. But the model suggested will work with any
overlay network - ATM, Ethernet, FR as long as we use the concept of
PN Tunnels. It is much easier for the administrator to just configure a
a logical port on the CE and then tunnel the PNNI signalling across 
the overlay networks with the help of a PN Tunnel ( whatever it may be
an LSP, L2TP Tunnel, IP VPN et al). On the PE, you just need to map
the cells/PDUs coming on VPI X to PN Tunnel Y and again on the egress
PE from PN Tunnel Y to VPI X. To Logical ports A and Logical ports B,
it will be as if they are immediate neighbors and talking to each other.

Regarding TE as i said it does not matter what the internal guarantees
for the VCs are. Anyway , the administrator will ensure that while
configuring the tunnel , he/she has enough bw associated with that
tunnel.Also, anyway in an ATM Network, when you tunnel VCs through a VP,
all the internal guarantees of the VCs are lost. 

We don't essentially require a one-to-one mapping from a VC to a
pseudo-wire as you need thousands of pseudo wires which may be an
administrative nightmare , especially if the VCs are signalled.

This model is much easier for a Service Provider to understand -
especially for those who have access and core ATM Networks and if they
are running PNNI/AINI et al. They can simply replace the core with
MPLS/IP and use the PNNI Tunneling thro PN Tunnels model to create
virtual ATM networks.

But i agree to the part that service interworking may not necessarily be
a part of this draft but PROBABLY can be a part of the addendum. It will
be a good workaround till the specs (both ATM Forum and IETF) are
finalized.

Thanks,
Raj Sarkar

[email-masked] wrote:
> 
> Raj,
> 
> Please see some comments below.
> 
> Best regards,
> 
> Matthew
> 
> -----------------------------------------
> Matthew Bocci
> Office of the CTO
> Alcatel Fixed Networks Division
> -----------------------------------------
> 
> |---------+--------------------------->
> |         |           Raj Sarkar      |
> |         |           <raj_sarkar@net.|
> |         |           com>            |
> |         |           Sent by:        |
> |         |           pwe3-admin@ietf.|
> |         |           org             |
> |         |                           |
> |         |                           |
> |         |           26/06/2003 23:59|
> |         |                           |
> |---------+--------------------------->
>   >-------------------------------------------------------------------------------------------------------------------------------|
>   |                                                                                                                               |
>   |        To:      [email-masked]                                                                                                 |
>   |        cc:                                                                                                                    |
>   |        Subject: [PWE3] Virtual ATM Networks over IP/MPLS(draft-ietf-pwe3-atm-encap-01.txt)                                    |
>   >-------------------------------------------------------------------------------------------------------------------------------|
> 
> Hi All,
> 
> This question is regarding the draft-ietf-pwe3-atm-encap-01.txt which is
> still a working document
> of the pwe3 group.
> 
>                  -------                    --------
> --------              --------
>                  |                 |                   |
> |                              |                     |              |
> |
>    ATM a )               O------OOOOOOOOOOOOOOOOOOOOOO---- O
> ( ATM b
>                           lport A             VPC Terminatio  to PN Tunnel
> to VPC Term         lport B
>                                    |                   |
> |                              |                      |              |
> |
>                  -------                   --------
> --------               -------
> 
> For simplicity i am assuming that the PN Tunnel is an MPLS LSP which
> traverses over an MPLS
> core network.
> 
> Now i want ATM Network a to talk to ATM Network b even without it being
> aware that the
> cells are travelling over an Non - ATM Network. Hypothetically, if we have
> two logical ports
> as in the diagram with signalling channels on them,  for the ATM Network it
> would be like
> 
>                             lport A  -----(logical link) ------- lport B
> 
> Hence, we can ideally tunnel signalling as well over the MPLS LSP. Why is
> this not a part of the
> working draft?
> 
> Matthew> What you describe is the port trunking service, which has been
> discussed at length on this list in the past, but I think it was decided to
> separate the encapsulations from the services that you could implement with
> them. You can implement this service using encapsulations described in the
> draft, depending on whether the logical link in the above diagram is the
> PSN tunnel, or the Pseudo-Wire. However, there are a number of issues with
> this service that make it harder to implement than might at first appear.
> The first issue is that ATM traffic contracts are defined on a per-ATM
> connection basis, not per-port. This makes it more difficult to apply
> traffic management to pseudo-wires to support ATM QoS without
> over-provisioning. There were also issues raised with regard to OAM and
> fault  management.
> 
> It actually makes the signalling interworking with MPLS much simpler in
> case of an ATM-MPLS
> -ATM netowrk. The administrator just needs to create two logical ports on
> the CE. Now the PE
> adds a LSP which maps the logical ports (VP Tunnels) VPI to an LSP. Now,
> following the draft
> recommendations the ATM cells are transported over the MPLS Network as well
> as the signalling packets. This will be much  simpler if we want to create
> ATM Networks over MPLS.
> 
> Matthew> Are you descibing tunnelling VPCs across the network (one VPI per
> logical port)? If so, this can be done with either the one to one or the N
> to one modes.
> As you correctly point out, tunnelling PNNI through the PSN is one of the
> simplest ways of interworking with the ATM control plane. This can be
> implemented without using a port trunking service and instead simply
> mapping the PNNI routing control channel and signalling channels to
> pseudo-wires, to transport the ATM control plane traffic. The ATM Forum has
> been working on an approach based on this for  awhile now.
> 
> Also, when TE comes into the picture, we should remember that whenever we
> use VP Tunnels
> in actual ATM Network , the individual VC guarantees are lost anyway. For
> efficiency, the
> PE can add an LSP with different diffserv codepoints. So, the CE can create
> CBR Logical ports,
> VBR Logical ports with CBR,VBR Traffic respectively and map it to an EF
> Queue or AF Queue
> in the PE Router.
> 
> Matthew> Put this a different way, if you use VPCs in an ATM network, the
> traffic contract is on the VPC. You must provision that VPC so that any QoS
> guarantees made to ATM VCs on it are supported.
> 
> Hence, using the following approach we can do PNNI Tunelling across the
> MPLS Network and
> create virtual ATM Networks.
> 
> Thanks,
> Raj Sarkar
> 
>  (See attached file: raj_sarkar.vcf)

---

From: Chris Metz <[email-masked]>
Date: Sun, 29 Jun 2003 09:27:23 -0700

Hey Raj-
The overlay models you describe come with the advantages (i.e. simplicity, 
transparency) and the burdens of any classic overlay approach. The burdens 
may be O(N^2) connection provisioning/managment scale and lack of 
per-connection QoS precision if we are using port or VP mode tunnels.

An alternative approach to solving this problem based on control plane 
interworking mechanisms is explored in:

http://ietf.org/internet-drafts/draft-metz-switched-atm-l2vpn-00.txt

In this solution ATM signaling/routing is terminated on the PE and 
"interworked" into PSN signaling and routing for carriage across the PSN. 
So MP-BGP propagates ATM prefixes (just like VPNv4 prefixes in 2547) 
between PEs and PNNI/AINI signaling drives concurrent PWE3 signaling in 
real-time with the latter bearing the contents of a switched VPC or VCC.

Why this approach over an overlay approach? Several reasons:

- providers already run (or plan to run) 2547-based services in their 
networks (i.e. IP VPN). Supporting switched ATM connectivity becomes just 
another service managed on PE using familiar protocol machinery and 
operations.

- providers can run a uniform set of PSN routing/signaling protocols. No 
need to extend PNNI adjacencies or create an overlay across the PSN which 
means you still have multiple networks to manage

- PE needs awareness of per-connection attributions for that extra 
precision in making appropriate connection-to-PW mapping decisions, marking 
EXP/DSCP bits, performing CAC or maybe even driving PSN resource allocations.

- need to work over non-MPLS networks (what if provider is IP-only?)

- need to support service interworking between switched ATM end-points and 
end-points attached to PE via static or non-ATM links.

- need to re-use leverage existing IETF PWE3 signaling/encaps (i.e. LDP, 
L2TPv3) and attendant mechanisms (i.e. LSP ping, VCCV, L2VPN IW) for 
management and troubleshooting of switched ATM connectivity across the PSN 
cloud.

Cheers ...

At 11:16 AM 6/27/2003 -0700, Raj Sarkar wrote:
> >   |        To:      [email-masked] 
> >   |        cc: 
> >   |        Subject: [PWE3] Virtual ATM Networks over 
> IP/MPLS(draft-ietf-pwe3-atm-encap-01.txt)                                    |
> >

---

From: Raj Sarkar <[email-masked]>
Date: Mon, 30 Jun 2003 15:00:54 -0700

Hi Chris,

I read the document, Interesting...

I have a few questions so I thought i will ask you:

<1> In Section <1> Page 6 - you have mentioned that we need to have
just a single session between the CE and the PE. What do you mean by a
single session here? 

What i understand from the draft document is that if we have three
physical links from the CE to the PE - each running PNNI , it will
appear as 3 distinct PNNI links to the destination CE . Right?
So , one instance of PWE3 Signalling will control these 3 instances of
SAAL/PNNI signalling. Inside the PSN, all these distinct links are lost.

Actually , i am interested to know how do you tunnel the distinct
control traffic across the PSN if you have 3 distinct physical links
each running PNNI across the PSN.

<2> Do you think it is wise to make BGP more complex by extending
support for ATM prefixes (BGP is complex anyway). Don't you think it is
becoming the "workaround" protocol for any problem we have in the IP
world. Why not use IP based addressing scheme here instead of extending
the BGP support for ATM prefixes? [ Assuming that we have an one-to-one
mapping between IP and ATM addresses and the Customer has the
flexibility of changing its ATM addresses..]. Then the PE needs to
convert the ATM prefixes to appropriate IP address and vice versa [Need
to think about this ??] .

<3> Now, tell me what happens when one of the nodes in the PSN fails and
only some of the pseudo-wires travel across that node. Actually, what
if the control traffic does not flow through a node , but a different
node? In this case the source and dst CE will still be connected while
the switched VCs may still get affected.. Actually once you explain <1>
, <3> will be clear as well.

<4> I saw that you have talked about the model i was proposing in Page 5
Introduction Section.1 . You talked that this approach has 2 drawbacks:

(i) A set of PWs and associated PN tunnels must be configured prior in a
partial or full mesh.

(ii) QOS - per VC QOS. But, nowhere we have addressed this in this
draft. So QOS is still a concern or follow the approach as specified in
Section 7.1 By the way, just out of curiosity did you read the recent
paper on IP QOS in IEEE Communication Magazine - "Scalability and
Quality of Service : A Trade-off?" by Michael Welzl and Max Muhlhauser.
Then, you will understand why i am saying that do we actually need to
keep per flow state in the core , in this case is the PSN network.

So, in conclusion, for the small CLECs or small business networks using
ATM access, we can still use the VP Tunnel overlay approach, since (ii)
is anyway not solved.

Thanks,
Raj Sarkar

Chris Metz wrote:
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3