Minutes of the Nasreq Working Group Meeting 44th IETF, Minneapolis Minn. Monday, March 15, 1999, 7:30 pm Chairs: Mark Beadles, Dave Mitton 1. Criteria Draft (draft-ietf-nasreq-criteria-00.txt) Mark Beadles led this discussion, working from the slides attached to these minutes. He reminded the group that the criteria document differs from a normal requirements document as described in RFC 1812. The criteria document does not say what functions are required in a NAS, but instead says how these functions must be performed if they are present. The Working Group's basic intent is to provide definitions and a reference model, and then to indicate where existing protocols apply within that model. The discussion proceeded from this point on the basis of the interfaces shown in the draft reference model. a. Client Interface: PPP support is considered a typical minimum, however the group is not ruling out coverage of mobile IP and use of IPSEC at the Client Interface. b. Network Interface: no remarks. c. AAA Interface: Mark's diagram showed this as "AAA Interface (Policy)". Concern was expressed that AAA is not the same as policy. Mark pointed out that there was a close relationship, since authorization is the means by which policy is enforced. The rejoinder to this was that the NAS could contain fixed policies, with the point being that policy could come from multiple sources. The conclusion of the meeting was that a policy interface should be added to the reference model. The suggestion was also made that a fourth "A" should be added to the AAA interface: Auditing. This may be viewed as Accounting information used in real time. d. Management Interface: no specific remarks. The general conclusion was that more discussion of the AAA, Policy, and Management interfaces was needed on the list before the Working Group could feel sure that it had defined the right reference model. A key point of the discussion should be the question: where does the NAS get policy from? The discussion moved on to consider the basic model as presented in the draft. "Telco or encapsulated" was renamed "User Sessions". "Modems or Virtual" was initially defined to be a source of PPP. Then Async and HDLC were added as possible inputs, with more possibilities in the offing. This caused further discussion, with the final conclusion that the function needs to be renamed. The group agreed to include Layer 2 switching as well as routing within the fabric of the NAS. This fits the US regulatory environment, which prevents RBOCs from doing routing within the Central Office. At that point the AD intervened to warn that the group should concentrate as narrowly as possible on functions unique to the NAS. It was noted in response that the group must take account of the needs of service providers. This led to a general discussion of the size of the job facing the Working Group. The AD suggested that the group choose PPP and/or Mobile IP and/or one or two access technologies, proceed to create the document, then accept additions provided that the authors can indicate the precise changes which must be made to the baseline document to accommodate the additions. Discussion then turned to the question of how telco signalling related to NAS requirements. Is signalling relevant? The answer is tied to the definition of the NAS as seen by Megaco and whether that defintion is consistent with the one being used by NASReq. In conclusion, the group must refine the definition of a NAS to the point where its boundaries become clear. Mark called for co-authors to help flesh out the document. Pat Calhoun will take on AAA, Matt Holdrege will contribute on signalling, and Alexander Catzko will work on management. 2. RADIUS Current Extended Practices Draft David Mitton gave a status update for the RADIUS draft. He apologized for narrowly missing the submission deadline and reminded attendees that it had been sent out to the list. The suggested file name is draft-ietf-nasreq-ext-radpract-00.txt. It was created from the Powerpoint presentation given at the last meeting, including the remarks received at that meeting. David will resubmit after cleaning up the formatting and boilerplate text. Discussion moved into the side issue of copyright. The material in the draft is summarized from, but does not quote directly, vendor-copyrighted material. Hence it can legally be issued as an Internet Draft without concern for copyright. A suggestion that it be sent out as an E-mail to the list to be totally safe was turned down because it would cause problems of its own, since copyright for E-mails accrues to their author. Matt Holdrege expressed the concern that RADIUS practices change regularly, so that the document would quickly be out of date. The response was that the group needs a current snapshot to work from, so the work has to be done and will be useful. David welcomes contributions of further descriptions of practice provided that no IPR is attached to these descriptions. The group noted that the RADIUS WG has concluded meeting, but still has some drafts being revised and awaiting final approval. 3. Presentation Of The Megaco Model Tom Taylor, Chair of the Media Gateway Control group (Megaco) presented a chart showing a possible interpretation of the Megaco architecture in terms of NASReq reference model. This chart showed the NAS as architectecturally equivalent to the combination of the Megaco Signalling Gateway (SG), Media Gateway Controller (MGC), and Media Gateway (MG) functions. The SG function takes message-based signalling (e.g. SS7, PRI) from the telephone network, terminates the lower layers, then passes the signalling PDUs to the MGC function. The latter could be called the NAS Controller function in the NASReq context. It responds to or originates telephony signalling on the one hand, and directs the MG function to perform the services required for each call on the other. For the NAS application, the MG function is responsible for the following: - detecting and reporting line or per-trunk (MF, R2) signalling to the MGC function - applying line and per-trunk signals in the outgoing direction as directed by the MGC - processing and routing of the user data flows. When the MGC and MG functions are in separate boxes, the control interface thus exposed carries the Megaco protocol. Tom pointed out that the AAA interface could terminate on either the MG or the MGC function, and that the alternative chosen would have a major effect on the content of information passing across the MGC-MG control interface. The general feeling of the group was that the AAA interface would terminate on the MG function. Tom indicated that the current Megaco requirements draft (draft-ietf-megaco-reqs-01.txt) contained an inadequate description of NAS-related requirements. draft-mitton-nasreqng-model-00.txt and the criteria draft, even in its current incomplete state, will be helpful in fleshing out the Megaco requirements. The suggested mapping of the Megaco architecture to the NASReq reference model was done hastily, and clearly took the meeting by surprise. A more careful mapping is required to allow the group to verify the validity of the Megaco requirements. Tom is prepared to work with NASReq to create that mapping. 4. Other Items A brief discussion ensued regarding items earlier excluded from the Working Group's consideration. The discussion was triggered by Mark's reference to tunneling servers. The key point noted was that the group should not restrict itself so much as to exclude the "next generation" aspect from its work. 5. Policy Framework Working Group John Strassner, Co-Chair of the Policy Framework Working Group, provided an update on his Working Group's activities. Essentially the aim of the group is to provide tools through which the SLA can be transformed through a series of steps ending up with the device which enforces it. The work derives originally from DEN, and the WG is cooperating with the DMTF so that they use the same policy models. The WG is adding conflict detection to the basic model. The core schema is close to last call. The architecture description has passed through multiple drafts with continuing contention between message passing versus signalling models. A cost schema will be created in a future effort. The intent is that the NAS will be the point where policy is implemented on the network. If the criteria draft needs a policy section, John Strassner volunteered to write it. 6. NASes and Roaming The NAS is being viewed as a gateway for roaming operations. ROAMOPS has accordingly been putting a lot of requirements onto the NAS (e.g. RFC 2477) which NASReq should take into account. 7. Review of Current Milestones The Chairs are considering an interim meeting to progress the criteria draft before Oslo. Details will be discussed on the mailing list.