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

From: Chris Metz <[email-masked]>
Date: Tue, 01 Jul 2003 10:27:14 -0700

Hey Raj-
Comments inline, thanks ...

At 03:00 PM 6/30/2003 -0700, Raj Sarkar wrote:
>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?

If the CE and PE are running PNNI then just a single PNNI adjacency (i.e 
RCC, signaling channel, etc.) is what is meant by a "control plane session".

>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?

Well it would be three PNNI links from the CE to the PE. Question I have is 
do operators typically have 3 distinct PNNI links connecting two adjacent 
ATM switches? Maybe if each link is associated with a particular traffic 
class. And then it is up to PNNI on the CE to direct the signaling message 
onto the appropriate link based on the requested traffic class of the 
signaled connection.

>So , one instance of PWE3 Signalling will control these 3 instances of
>SAAL/PNNI signalling. Inside the PSN, all these distinct links are lost.

PNNI topology and signaling awareness is terminated on the PE. PWE3 
signaling can accept and interwork inbound PNNI signaling from any inbound 
CE-PE link.

>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.

PNNI topology data is terminated on the PE. The contents of PNNI signaling 
messages associated with a connection setup/maintanance/teardown are 
received at the PE, packaged up in a TLV and carried in a PWE3 signaling 
message to the remote PE. Which remote PE depends upon several factors 
including type of PNNI signaling message, reachability to the destination 
ATM prefix and so on. For example if it is a connection setup, then we do a 
longest prefix match of the called party address and entries in the ATM VRF 
to resolve the remote PE address.

><2> Do you think it is wise to make BGP more complex by extending
>support for ATM prefixes (BGP is complex anyway).

BGP is not simple, you got that right :-)

>Don't you think it is
>becoming the "workaround" protocol for any problem we have in the IP
>world.

Not necessarily ... it is a routing protocol designed to propagate 
multi-protocol address family prefixes in a scalable and controllable 
manner. And it does not need to in any way touch the core elements. So I 
would argue that this is just the application that MP-BGP was designed for. 
Again it is being used to distribute address prefixes to multiple parties 
(PEs). We are not suggesting its use as a signaling protocol for this type 
of L2VPN ....

>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 ??] .

That would be preferable but in the real world I don't know of many 
customers who would renumber their ATM networks. You will need a routing 
protocol (like MP-BGP) to   distribute these prefixes and place them in the 
appropriate VRF.

><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.

PSN node or link failures are handled by IP and/or MPLS recovery and 
reroute mechanisms. There is a slew of different (and emerging) mechanisms 
that can identify and reroute around failed links or nodes in 10s of 
milliseconds (i.e. MPLS FRR) and in some situations keep traffic flowing 
(i..e. graceful restart, non-stop forwarding). So the intent is that 
hiccups inside the PSN should be transparent to end-to-end switched ATM 
connection function.

>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.

This is not a drawback per se. But it could be if you have a large number 
of PW and PSN tunnels to configure. Should be fine for manageable number 
and that is up to the operator to decide.

The other issue that I have heard from carriers is that you need to 
over-provision these PW and PSN tunnels which can be viewed as being 
resource inefficient.

>(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

Right section 7 discusses several approaches.

>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.

This is probably not the appropriate forum to review IEEE papers but yes I 
did that article. His argument for scalability using the analogy of 
aggregation via many students-several tutors-one professor versus fined 
grained service ala many students-one professor was clever. However I don't 
agree with the observation that the quality of service was impacted via 
aggregation. To the student, a useful insight/tip is just that ... should 
not matter that the professor or the tutor dispensed it. Just like an ATM 
end-point should not care if per-VC state is maintained in the core or not.

PS- I tutored undergrads in college, my feelings are hurt :-(

>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.

Yes if the network is small then keep it simple.

Thanks ...

>Thanks,
>Raj Sarkar
>
>Chris Metz wrote:
> >
> > 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:
> > >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)
> >
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Mustapha Aissaoui <[email-masked]>
Date: Wed, 02 Jul 2003 17:16:47 -0400

Raj,
see comments inline.

Mustapha.
------------

> it will be as if they are immediate neighbors and talking to each other.

MA> this solution works for service providers who sell a VP service on the UNI to their customers. As you explain, there is nothing
special that needs to be done at the except for the encapsulation/decapsulation of cells into/from MPLS packets and the transparent
tranport of OAM and control plane messages.

> administrative nightmare , especially if the VCs are signalled.

MA>The ATM Forum extended PNNI specification is intended to service providers who sell a VC service to their customers:
a. either a SVC service CE-to-CE,
b. or a SPVC service to connect the endpoints on PE (network side of the UNI) to which customer equipment are attached.

> >   |        To:      [email-masked]                                                                                                 |
> >   |        cc:                                                                                                                    |
> >   |        Subject: [PWE3] Virtual ATM Networks over IP/MPLS(draft-ietf-pwe3-atm-encap-01.txt)                                    |
> > This question is regarding the draft-ietf-pwe3-atm-encap-01.txt which is
> > still a working document
> > of the pwe3 group.
> >
> >                  -------                    --------
> > --------              --------
> >                  |                 |                   |
> > |                              |                     |              |
> > |
> >                           lport A             VPC Terminatio  to PN Tunnel
> > to VPC Term         lport B
> >                                    |                   |
> > |                              |                      |              |
> > |
> >                  -------                   --------
> > --------               -------
> >
> > 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?
> >
> > 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.
> > -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
> > pseudo-wires, to transport the ATM control plane traffic. The ATM Forum has
> > 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,
> > 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