Subject: (ION) PVC autoconfiguration and IPOA

From: Paul Koning <[email-masked]>
Date: Wed, 26 May 1999 09:56:20 -0400

I recently found out about an ATM Forum spec af-nm-0122,
"Auto-configuration of PVCs".  There's some interest in that, because
it creates a middle ground between the management hassles of
conventional PVCs and the algorithmic complexity of SVCs.

What isn't clear to me is what, if any, connection there is between
that work and IPOA.  The ATM related MIBs (AToM and IPOA) treat PVCs
as something configured at the end system.  In particular, it is not
clear to me how a PVC that just materializes at an end system via the
magic of af-nm-0122 can then become bound to a Logical IP Subnet and
start running IPOA.

Has any work been done in this area?  Is there interest?

Thanks,
	paul
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 27 May 1999 16:54:36 -0400 (EDT)

Paul,

Typically, for IP over ATM, PVCs are used to for point-point router
interconnection rather than as a connection to or from a host in a LIS.

In that context, when the router, via the new mechanisms in the ILMI
MIB, sees a new PVC come up, it would then use INATMARP, as specified
in RFC 2225 section 8.2, to get the IP address of its peer and treats
it as a new point-to-point link to that peer.  If so configured, the
router would then bring up routing with this peer.

This is identical to what FR interfaces on routers do when they they
see PVCs coming up, or new PVCs created, in the FR PVC status signaling
from the network.

So I don't think we need to specify anything new .... people just have
to get this into their implementations.

Cheers, 
Andy

-------

> Has any work been done in this area?  Is there interest?
________________________________________________________________________
Andrew G. Malis  [email-masked]  phone:978 952-7414   fax:978 392-2074
Ascend Communications, Inc.        1 Robbins Road     Westford, MA 01886

---

From: Paul Koning <[email-masked]>
Date: Thu, 27 May 1999 17:11:00 -0400

>>>>> "Andrew" == Andrew G Malis <[email-masked]> writes:

 Andrew> Paul, Typically, for IP over ATM, PVCs are used to for
 Andrew> point-point router interconnection rather than as a
 Andrew> connection to or from a host in a LIS.

 Andrew> In that context, when the router, via the new mechanisms in
 Andrew> the ILMI MIB, sees a new PVC come up, it would then use
 Andrew> INATMARP, as specified in RFC 2225 section 8.2, to get the IP
 Andrew> address of its peer and treats it as a new point-to-point
 Andrew> link to that peer.  If so configured, the router would then
 Andrew> bring up routing with this peer.

 Andrew> This is identical to what FR interfaces on routers do when
 Andrew> they they see PVCs coming up, or new PVCs created, in the FR
 Andrew> PVC status signaling from the network.

 Andrew> So I don't think we need to specify anything new .... people
 Andrew> just have to get this into their implementations.

I know that not everyone is as hardnosed about spelling out things in
specs as I tend to be.  The trouble with the scenario you describe is
that it doesn't seem to be covered by the specs as they stand.  Yes,
you can extrapolate the behavior you mentioned.  It seems logical,
especially given the FR precedent.

On the other hand, what are the implications in the MIB?  Normally,
PVCs appear in the configured PVC table.  Would these?  I suppose they 
might, but that seems odd since that table is writable and these
entries probably should not be.  And they aren't configured (at the
end system).  So I suppose they could just appear in the VC table,
with type PVC but no configPvc table entry.

And what if the traffic parameters passed by ILMI don't match any
entry in the traffic table?  Would I automagically create one?

Clearly I can think up solutions for this, but it does seem to me that 
some of the issues are visible to management, hence need to be
specified in the MIB.  

Thanks,
	paul

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 28 May 1999 08:48:59 -0400 (EDT)

Paul,

Sorry, I fat-fingered my previous reply.

> especially given the FR precedent.

It's actually well covered in RFC 2390, which used FR as an example,
but could easily be extrapolated to cover ATM when read as a companion
to 2225.  The Inverse ARP RFC (1293 at that time) is also referenced by
2225.  And as Juha noted, it is already in implementations.

> On the other hand, what are the implications in the MIB?  
> Normally, PVCs appear in the configured PVC table.  Would these?  
> I suppose they might, but that seems odd since that table is
> writable and these entries probably should not be.  And they aren't
> configured (at the end system).  So I suppose they could just
> appear in the VC table, with type PVC but no configPvc table entry.
>
> Clearly I can think up solutions for this, but it does seem to me
> that some of the issues are visible to management, hence need to be
> specified in the MIB.

I was reminded by another correspondent that the intended application
for af-nm-0122 wasn't router interconnection, or even for directly
carrying IP, but rather to support ADSL access.  Since the protocol
stack agreed upon by the ADSL Forum is IP over PPP over ATM over ADSL,
ATM PVCs or SVCs are required between the ATU-R in the home and the
ADSL service concentrator to carry the PPP sessions.  If the vendor or
service provider only wants to support PVCs in the ATU-R, then
af-nm-0122 removes the need for the PVCs to be manually configured in
the ATU-Rs.  You should probably evaluate af-nm-0122 in that context.

Cheers,
Andy

---

From: Paul Koning <[email-masked]>
Date: Fri, 28 May 1999 13:41:24 -0400

>> writable and these entries probably should not be.  And they
 >> aren't configured (at the end system).  So I suppose they could
 >> just appear in the VC table, with type PVC but no configPvc table
 >> entry.
 >> 
 >> that some of the issues are visible to management, hence need to
 >> be specified in the MIB.

 Andrew> I was reminded by another correspondent that the intended
 Andrew> application for af-nm-0122 wasn't router interconnection, or
 Andrew> even for directly carrying IP, but rather to support ADSL
 Andrew> access.  Since the protocol stack agreed upon by the ADSL
 Andrew> Forum is IP over PPP over ATM over ADSL, ATM PVCs or SVCs are
 Andrew> required between the ATU-R in the home and the ADSL service
 Andrew> concentrator to carry the PPP sessions.  If the vendor or
 Andrew> service provider only wants to support PVCs in the ATU-R,
 Andrew> then af-nm-0122 removes the need for the PVCs to be manually
 Andrew> configured in the ATU-Rs.  You should probably evaluate
 Andrew> af-nm-0122 in that context.

I heard the same from another source, but that doesn't eliminate the
question.  PPP over ATM means the IPOA MIB is out of the picture, but
the AToM MIB isn't.  I still have the question of how (or whether) Vcl
table entries and traffic descriptor entries are generated as a
consequence of autoconfiguration.

Also, I've heard some interest in this topic from people who do want
to run IPOA.

To put the question differently: I realize I can whip up a proprietary 
hack easily, and/or do something that ignores the MIBs entirely.  But
is there any interest in doing work in the WG to cover this
autoconfiguration stuff, minimally its impact on the MIB and possibly
(if there is some) its impact on the protocol specs?

Thanks,
	paul

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 28 May 1999 15:23:18 -0400 (EDT)

Paul,

> consequence of autoconfiguration.

That particular discussion is probably more appropriate on the atommib
list.

> Also, I've heard some interest in this topic from people who do
> want to run IPOA. To put the question differently: I realize I can
> whip up a proprietary hack easily, and/or do something that ignores
> the MIBs entirely.  But is there any interest in doing work in the
> WG to cover this autoconfiguration stuff, minimally its impact on
> the MIB and possibly (if there is some) its impact on the protocol
> specs?

You've asked the question, let's see if there's any interest.

One thing to keep in mind is that the WG is (at least officially) not
active, although we've got dispensation to complete work on the
existing drafts, so there may be pushback from the ADs on anything new
like this.  However, RFC 2320 HAS been out for a year now, so it may be
a good time for a volunteer to start canvasing for implementation
experience and suggestions for improvement (hint, hint).

Cheers,
Andy

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 29 May 1999 08:39:52 +0300 (EEST)

> (if there is some) its impact on the protocol specs?

it would be a good idea to document the commonly used hacks so that it
would be easier for the new vendor to understand what needs to be done.

-- juha