[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ANCP] missing items in the ancp-mib draft
Hi Markus,
The parameters related to control channel has been intentionally not
been included in the ANCP MIB because these attributes are to be
configured in other MIBs. For instance, if the VLAN on which ANCP is
running needs p-bit 5, then that is to be configured in the
corresponding ethernet MIB where VLANs are configured. The same for
PVCs: I guess there are ATM MIBs where the attributes of all the PVCs
can be configured.
Then you also need the selection of the VLAN or PVC to be used for ANCP.
Actually, ANCP are IP packets originated from an IP address in the AN,
and transmitted like any other IP packet, i.e., the AN performs an IP
lookup in its routing table. So if the correct routing cannot be
achieved because the IP address of the directly attached interface of
the "ANCP VLAN" is not used as NAS address, then an appriopriate route
has to be configured such that these packets are going to the VLAN on
which they should be. However, also this "routing information" (in
whatever form) is to be configured in other MIBs than the ANCP MIB.
Look it like this in case of ethernet: if the AN generates an ANCP
message to the NAS, then the ANCP message is put in an ethernet frame,
this ethernet frame needs a MAC destination address. To get the MAC
destination address, the AN has to send an ARP to an IP address. This
IP address is the next-hop IP address, which it gets from the routing
information. It can be a next-hop of a route, or in case the NAS IP
address is directly attached, the IP packet matches the direct route.
So I have the feeling that this "routing information" for ANCP can exist
in multiple forms:
(1) a route with next-hop, or directly attached
(2) a VLAN (so no next-hop and then the NAS IP must be directly attached
for sending an ARP).
- ...
So I have the feeling that this just do not belong to an ANCP MIB. For
sure option (1) should not be in the ANCP MIB, (2) could be added but
since a generic solution anyhow requires (1), I do not see the need to
add something in the ANCP MIB.
Extra filters in the ANCP MIB could be added like for instance that ANCP
messages may only be sent or received on particular VLANs, but that is
just an extra ACL, and each implementation can add as much security as
needed and this should maybe not be in a standard ANCP MIB.
Do you agree with this?
Thanks for the review, all comments are very welcome.
regards,
Stefaan
Freudenberger, Markus wrote:
> Hi all,
>
> looking into the actual ancp-mib draft, I am misssing the following:
>
> 1) the possibilty to configure the IP address on the AN for the control channel as it is already defined for the peer NAS. This implies adding additional entries into the ancpAnCurrentSessionTable for reading the control channel ip address of the NAS.
>
> 2) the possibility to configure the allocation of control channel(s) to a physical interface with VPI/VCI resp. C-/S-VAN-ID values and Qos/CoS setting.
>
> Both is required to allow the EMS the setup of the control channel with SNMP and this is described in Section 6 of the ancp framework document anyway (See below).
>
> ----------------------- snip from draft-ietf-ancp-framework-04.txt -----------------------
> 6. Management Related Requirements
>
> o It must be possible to configure the following parameters on the
> Access Node and the NAS:
>
> * Parameters related to the Control Channel transport method:
> these include the VPI/VCI and transport characteristics (e.g.
> VBR-rt or CBR) for ATM networks or the C-VLAN ID and S-VLAN ID
> and p-bit marking for Ethernet networks;
>
> * Parameters related to the Control Channel itself: these include
> the IP address of the IP interface on the Access Node and the
> NAS
> ----------------------- snip from draft-ietf-ancp-framework-04.txt -----------------------
>
> Any comments?
>
> Regards
> Markus Freudenberger
>
> T-Systems Enterprise Services GmbH
> Systems Integration
> Telco Project & Design
> Line of Business Networks & Processes
> Technology Consultant
> Deutsche-Telekom-Allee 7, D-64295 Darmstadt
> +49 6151 937-3679 (Phone)
> +49 6151 937-19875 (Fax)
> +49 521 5224 5816 (PC-Fax)
> E-Mail: mailto:markus.freudenberger at t-systems.com
> Internet: http://t-systems.com
>
>
>>T-Systems Enterprise Services GmbH
>>Aufsichtsrat: René Obermann (Vorsitzender)
>>Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, Wilfried Peters*,
>>Dr. Herbert Schaaff*, Zvezdana Seeger*
>>Handelsregister: Amtsgericht Frankfurt am Main HRB 55933
>>Sitz der Gesellschaft: Frankfurt am Main
>>WEEE-Reg.-Nr. DE87523644
>>*Geschäftsführer gem. § 35 GmbHG
>>
>
> Notice: This transmittal and/or attachments may be privileged or confidential. If you are not the intended recipient, you are hereby notified that you have received this transmittal in error; any review, dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you.
> T-Systems - Business flexibility
>
>
> _______________________________________________
> ANCP mailing list
> ANCP at ietf.org
> http://www.ietf.org/mailman/listinfo/ancp
_______________________________________________
ANCP mailing list
ANCP at ietf.org
http://www.ietf.org/mailman/listinfo/ancp