From owner-ipcdn@terayon.com Tue Feb 1 13:39:30 2000 Received: from www.terayon.com (terayon.com [157.22.250.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28117 for ; Tue, 1 Feb 2000 13:39:29 -0500 (EST) Received: from redpine.terayon.com (redpine [157.22.250.5]) by www.terayon.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id KAA21815 for ; Tue, 1 Feb 2000 10:39:27 -0800 (PST) Received: from mail-serv.terayon.com by redpine.terayon.com via smtpd (for mails.terayon.com [157.22.250.1]) with SMTP; 1 Feb 2000 18:39:27 UT Received: from tamarind.terayon.com (tamarind.terayon.com [172.20.0.6]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id KAA28751; Tue, 1 Feb 2000 10:39:19 -0800 (PST) Received: (from root@localhost) by tamarind.terayon.com (8.8.8+Sun/8.8.8) id KAA05789 for ipcdn-outgoing; Tue, 1 Feb 2000 10:31:43 -0800 (PST) Message-Id: <200002011831.NAA02150@dragonfly.corp.home.net> X-Mailer: exmh version 2.1.0 09/18/1999 To: ipcdn@terayon.com Subject: Re: Call for agenda items - Adelaide IETF meeting In-Reply-To: Your message of "Mon, 31 Jan 2000 09:43:24 PST." <4.2.2.20000131094120.00dec5c0@poptart> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Feb 2000 13:31:48 -0500 From: Ran Atkinson Sender: owner-ipcdn@terayon.com Precedence: bulk Reply-To: ipcdn@terayon.com EuroModem should be part of the agenda, IMHO. Ran From owner-ipcdn@terayon.com Thu Feb 3 23:13:30 2000 Received: from www.terayon.com (terayon.com [157.22.250.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06910 for ; Thu, 3 Feb 2000 23:13:30 -0500 (EST) Received: from redpine.terayon.com (redpine [157.22.250.5]) by www.terayon.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id UAA25048 for ; Thu, 3 Feb 2000 20:13:26 -0800 (PST) Received: from mail-serv.terayon.com by redpine.terayon.com via smtpd (for mails.terayon.com [157.22.250.1]) with SMTP; 4 Feb 2000 04:13:26 UT Received: from tamarind.terayon.com (tamarind.terayon.com [172.20.0.6]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id UAA28471; Thu, 3 Feb 2000 20:13:13 -0800 (PST) Received: (from root@localhost) by tamarind.terayon.com (8.8.8+Sun/8.8.8) id UAA08323 for ipcdn-outgoing; Thu, 3 Feb 2000 20:11:29 -0800 (PST) Message-ID: <4DF5E8A771ECD21187020008C7B1C5AF9842BE@srvmail.cablelabs.com> From: Kazuyoshi Ozawa To: "'Rich Woundy'" , ipcdn@terayon.com Cc: DOCSIS OSS Majordomo List Subject: RE: "Final" BPI (not BPI+) MIB Date: Thu, 3 Feb 2000 21:11:00 -0700 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-ipcdn@terayon.com Precedence: bulk Reply-To: ipcdn@terayon.com One question on docsBpiIpMulticastPrefixLength I assume that the PrefixLength makes the mask as follows. 0 - mask of 0x00000000 1 - mask of 0x80000000 8 - mask of 0xff000000 32 - mask of 0xffffffff Then compares { actuall IP Multicast Address AND mask } and { docsBpiIpMulticastAddress AND mask } Is this correct ? Thanks, kaz > -----Original Message----- > From: Rich Woundy [mailto:rwoundy@cisco.com] > Sent: Monday, January 31, 2000 10:30 AM > To: ipcdn@terayon.com > Cc: docsis-oss@cablelabs.com > Subject: "Final" BPI (not BPI+) MIB > > > Folks, > > I have attached what I hope to be the final DOCSIS Baseline > Privacy MIB > (for pre-BPI+ modems). Again, it has been verified using > smicng. I will > followup this note with the proposed Internet draft. > > The differences from the January 7, 2000 version are: > > 1. Commented out some "relaxations on mandatory ranges" in > the compliances > statements, since these relaxations are unnecessary for read-only MIB > objects (each "relaxation" shrinks the legal value range of > each object). > This affects compliance statements for docsBpiCmAuthGraceTime, > docsBpiCmTEKGraceTime, docsBpiCmtsAuthCmGraceTime, and > docsBpiCmtsTEKGraceTime. > 2. Updated numbering of external references (new > bibliography) and other > minor cleanup, to support the new internet draft. > > Please send comments by Friday morning. There should be no > real surprises > here. > > -- Rich > > From owner-ipcdn@terayon.com Thu Feb 3 23:29:13 2000 Received: from www.terayon.com (terayon.com [157.22.250.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06974 for ; Thu, 3 Feb 2000 23:29:12 -0500 (EST) Received: from redpine.terayon.com (redpine [157.22.250.5]) by www.terayon.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id UAA25305; Thu, 3 Feb 2000 20:29:01 -0800 (PST) Received: from mail-serv.terayon.com by redpine.terayon.com via smtpd (for mails.terayon.com [157.22.250.1]) with SMTP; 4 Feb 2000 04:29:01 UT Received: from tamarind.terayon.com (tamarind.terayon.com [172.20.0.6]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id UAA29045; Thu, 3 Feb 2000 20:29:00 -0800 (PST) Received: (from root@localhost) by tamarind.terayon.com (8.8.8+Sun/8.8.8) id UAA08556 for ipcdn-outgoing; Thu, 3 Feb 2000 20:28:09 -0800 (PST) Message-ID: <4DF5E8A771ECD21187020008C7B1C5AF9842BF@srvmail.cablelabs.com> From: Kazuyoshi Ozawa To: "'Rich Woundy'" , ipcdn@terayon.com Cc: DOCSIS OSS Majordomo List Subject: RE: BPI (not BPI+) MIB Internet Draft Date: Thu, 3 Feb 2000 21:28:14 -0700 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-ipcdn@terayon.com Precedence: bulk Reply-To: ipcdn@terayon.com Rich, I have a couple of comments. section 2.7 According to CableLabs' definition, "Data-Over-Cable Service Interface Specifications" instead of "Data Over Cable Interface Specification" section 3.2, 2nd bullet says; The Baseline Privacy management interface needs to support operator configuration of Authorization and TEK Finite State Machine (FSM) parameters, for performance tuning and security incident handling. The CMTS MUST support configuring and viewing all FSM-related parameters, including baseline privacy status (enabled or disabled), key lifetimes, key grace times, and state timeout values. The CM MUST support viewing these parameters where possible. I understand that, while the BPI MIB does not support configuring the baseline privacy status, etc, I think the above paragraph is a general requirement for OSSI and the above paragraph is fine. (If the above paragraph is a requirement for the MIB, it may be better to remove "configuring and".) section 6, References [18] through [21], the URLs for these documents have been changed. I think we only be able to specify http://www.cablemodem.com/ for all of these 4 documents. Thanks, kaz Kaz Ozawa Toshiba Visiting Engineer at CableLabs Tel: 303-661-3860 (direct); 9199 (fax); 9100 (main) Email: k.ozawa@cablelabs.com / kaz@pobox.com From owner-ipcdn@terayon.com Thu Feb 3 23:38:07 2000 Received: from www.terayon.com (terayon.com [157.22.250.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07425 for ; Thu, 3 Feb 2000 23:38:07 -0500 (EST) Received: from redpine.terayon.com (redpine [157.22.250.5]) by www.terayon.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id UAA25545; Thu, 3 Feb 2000 20:37:47 -0800 (PST) Received: from mail-serv.terayon.com by redpine.terayon.com via smtpd (for mails.terayon.com [157.22.250.1]) with SMTP; 4 Feb 2000 04:37:47 UT Received: from tamarind.terayon.com (tamarind.terayon.com [172.20.0.6]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id UAA29454; Thu, 3 Feb 2000 20:37:46 -0800 (PST) Received: (from root@localhost) by tamarind.terayon.com (8.8.8+Sun/8.8.8) id UAA08701 for ipcdn-outgoing; Thu, 3 Feb 2000 20:36:58 -0800 (PST) Message-ID: <4DF5E8A771ECD21187020008C7B1C5AF9842C0@srvmail.cablelabs.com> From: Kazuyoshi Ozawa To: "'Rich Woundy'" , ipcdn@terayon.com Cc: DOCSIS OSS Majordomo List Subject: RE: "Final" BPI (not BPI+) MIB Date: Thu, 3 Feb 2000 21:36:33 -0700 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-ipcdn@terayon.com Precedence: bulk Reply-To: ipcdn@terayon.com 2 minor comments. (1) Many objects contain "Note: this object will be read-write accessible only after....." in their DESCRIPTION. While this is not a technical problem at all, they can be removed now..... But I'm not sure. (2) docsBpiCmTEKEntry If I understand correctly, the entry is only for unicast and we should remove "or multicast" from DESCRIPTION. Thanks, kaz From owner-ipcdn@terayon.com Fri Feb 4 00:52:28 2000 Received: from www.terayon.com (terayon.com [157.22.250.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07943 for ; Fri, 4 Feb 2000 00:52:27 -0500 (EST) Received: from redpine.terayon.com (redpine [157.22.250.5]) by www.terayon.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id VAA26118 for ; Thu, 3 Feb 2000 21:52:25 -0800 (PST) Received: from mail-serv.terayon.com by redpine.terayon.com via smtpd (for mails.terayon.com [157.22.250.1]) with SMTP; 4 Feb 2000 05:52:25 UT Received: from tamarind.terayon.com (tamarind.terayon.com [172.20.0.6]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id VAA01022; Thu, 3 Feb 2000 21:52:15 -0800 (PST) Received: (from root@localhost) by tamarind.terayon.com (8.8.8+Sun/8.8.8) id VAA09136 for ipcdn-outgoing; Thu, 3 Feb 2000 21:50:35 -0800 (PST) Message-Id: <200002040550.AAA28546@funnel.cisco.com> X-Sender: rwoundy@funnel X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 04 Feb 2000 00:54:23 -0500 To: Kazuyoshi Ozawa , ipcdn@terayon.com From: Rich Woundy Subject: RE: "Final" BPI (not BPI+) MIB Cc: DOCSIS OSS Majordomo List In-Reply-To: <4DF5E8A771ECD21187020008C7B1C5AF9842BE@srvmail.cablelabs.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipcdn@terayon.com Precedence: bulk Reply-To: ipcdn@terayon.com Kaz, Your interpretation is correct. Does this need to be clarified in the MIB? -- Rich At 09:11 PM 2/3/00 -0700, Kazuyoshi Ozawa wrote: >One question on docsBpiIpMulticastPrefixLength > >I assume that the PrefixLength makes the mask as follows. > >0 - mask of 0x00000000 >1 - mask of 0x80000000 >8 - mask of 0xff000000 >32 - mask of 0xffffffff > >Then compares { actuall IP Multicast Address AND mask } >and { docsBpiIpMulticastAddress AND mask } > >Is this correct ? > >Thanks, >kaz > >> -----Original Message----- >> From: Rich Woundy [mailto:rwoundy@cisco.com] >> Sent: Monday, January 31, 2000 10:30 AM >> To: ipcdn@terayon.com >> Cc: docsis-oss@cablelabs.com >> Subject: "Final" BPI (not BPI+) MIB >> >> >> Folks, >> >> I have attached what I hope to be the final DOCSIS Baseline >> Privacy MIB >> (for pre-BPI+ modems). Again, it has been verified using >> smicng. I will >> followup this note with the proposed Internet draft. >> >> The differences from the January 7, 2000 version are: >> >> 1. Commented out some "relaxations on mandatory ranges" in >> the compliances >> statements, since these relaxations are unnecessary for read-only MIB >> objects (each "relaxation" shrinks the legal value range of >> each object). >> This affects compliance statements for docsBpiCmAuthGraceTime, >> docsBpiCmTEKGraceTime, docsBpiCmtsAuthCmGraceTime, and >> docsBpiCmtsTEKGraceTime. >> 2. Updated numbering of external references (new >> bibliography) and other >> minor cleanup, to support the new internet draft. >> >> Please send comments by Friday morning. There should be no >> real surprises >> here. >> >> -- Rich >> >> > From owner-ipcdn@terayon.com Fri Feb 11 19:20:54 2000 Received: from www.terayon.com (terayon.com [157.22.250.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27140 for ; Fri, 11 Feb 2000 19:20:50 -0500 (EST) Received: from redpine.terayon.com (redpine [157.22.250.5]) by www.terayon.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id QAA29145 for ; Fri, 11 Feb 2000 16:20:28 -0800 (PST) Received: from mail-serv.terayon.com by redpine.terayon.com via smtpd (for mails.terayon.com [157.22.250.1]) with SMTP; 12 Feb 2000 00:20:28 UT Received: from tamarind.terayon.com (tamarind.terayon.com [172.20.0.6]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id QAA24457; Fri, 11 Feb 2000 16:19:22 -0800 (PST) Received: (from root@localhost) by tamarind.terayon.com (8.8.8+Sun/8.8.8) id QAA03387 for ipcdn-outgoing; Fri, 11 Feb 2000 16:17:10 -0800 (PST) Message-Id: <200002120017.TAA14189@funnel.cisco.com> X-Sender: rwoundy@funnel X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 11 Feb 2000 19:20:49 -0500 To: ipcdn@terayon.com From: Rich Woundy Subject: DOCSIS and DVB MIB Comparision Cc: a_valentine@hnsltd.hns.com, stjohns@corp.home.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipcdn@terayon.com Precedence: bulk Reply-To: ipcdn@terayon.com Folks, Andrew Valentine (Hughes Network Systems) and I have been working on the comparison between the DOCSIS Cable Device MIB and the DVB NIU MIB. In addition, we've thought a little bit about potentially merging the two MIBs for future products such as dual DOCSIS/DVB set-top boxes. Separately, Andrew is planning to publish the DVB NIU MIB as an Internet draft. This MIB is the subject of this comparison report, and is similar to the "Euromodem MIB" that Andrew posted to the ipcdn mailing list on 10/6/99. I suspect that folks reading this report will generate comments back to this mailing list, as well as in Adelaide. -- Rich DOCSIS and DVB MIB Comparision for Potential Merging First of all, why should we attempt to merge the DOCSIS Cable Device and DVB NIU MIBs? There are two primary reasons for merging at least part of the DOCSIS Cable Device MIB with the DVB/Euromodem NIU MIB. First, the industry expects the deployment of OpenCable and other advanced digital set-top boxes, which contain both DOCSIS and DVB interfaces, likely under the control of a single CPU with a single SNMP agent. Successful deployment of these devices requires the following MIB objects that are not addressed by independent MIBs: - an object that allows the MSO to reset the entire box, in addition to objects to reset the DOCSIS and DVB components individually, - objects representing "upstream traffic direction", that determine whether upstream packets are forwarded to the DOCSIS or DVB component, - objects managing "network management access" that consistently control access to each modem's consolidated SNMP agent, and - objects representing a consolidated "event log" for both DOCSIS and DVB events that preserve sequences of events (to help isolate cable plant issues from DOCSIS CMTS/DVB INA issues). Second, the industry would benefit from consistency in cable modem management. The CM vendors could reuse some SNMP agent software between DOCSIS and DVB modems (and simplify software for an integrated DOCSIS/DVB modem). The network management software vendors could write the same or similar management applications, particularly managing the common MIB objects for DOCSIS and DVB. DVB NIU (Revision 9912010000Z) and DOCSIS Cable Modem (RFC2669) MIB Comparison Only the objects in the DOCSIS MIB which are applicable to the modem have been compared. The objects are compared in the order they appear in the MIBs. KEY (DOC) DOCSIS only object (DVB) DVB only object (DIF) Common object but different definition (SIM) Similar object with similar definition OBJECTS (DVB) dvbNiuModemtype: Type of modem (DOC) docsDevRole: Role of DOCSIS device (DVB) dvbNiuMibVersion: Version of Niu MIB (SIM) dvbNiuDateAndTime / docsDevDateTime (DIF) dvbNiuResetNow / docsDevResetNow: Control reset of device DVB object uses an Enumerated, DOCSIS MIB uses a TruthValue. (DVB) dvbNiuResetCounts: Count of resets since power on (DIF) dvbNiuSerialNum / docsDevSerialNumber DVB object includes manufacturer, model, revision. DOCSIS puts similar attributes into the System sysObjectID object: vendor ID, hardware platform, hardware revision, software/PROM revision (major, minor, patch numbers). The sysDescr object conveys the same information in human-readable form. See DOCSIS SP-OSSI-RFI-I03-990113. (DOC) docsDevSTPControl: Bridging spanning tree control (DVB) dvbStaticIpTable (entire table): Static IP configuration of interfaces (DIF) dvbNiuNmAccessTable / docsDevNmAccessTable (entire table): NM access table DVB object states that an empty table only allows management access via the HFC interface. (DIF) dvbNiuNmAccessStatus / docsDevNmAccessStatus: RowStatus DVB object states that "Rows can be modified/deleted ONLY if the SNMP set request source IP address will not be denied access after the set request is actioned." (DVB) dvbNiuConfigSet: Controls the storage of configuration information (DVB) dvbNiuEuroLoader: Controls EuroLoader (DVB) dvbNiuImplSet: Identifies which optional groups have been implemented (DVB) dvbNiuSwVerTable (entire table): Table to manage multiple CM software images (SIM) dvbNiuSwServer / docsDevSwServer: TFTP server for software upgrades (DIF) dvbNiuSwFilename / docsDevSwFilename: Filename of image to download DOCSIS object has concept of DHCP-supplied filename. (DVB) dvbNiuSwDownloadSlot: Select memory slot to download image into (DIF) dvbNiuAdminStatus / docsDevSwAdminStatus + docsDevSwOperStatus The DVB object combines the two DOCSIS objects. The DOCSIS and DVB enumerations are different, and are technology-specific. (DOC) docsDevSwCurrentVers: Current operational software version (DVB) dvbNiuDhcpTable (entire table): DHCP control table (DVB) dvbNiuOperStatus: Operation status of box (DOC) docsDevServerBootState: Boot state of box (DOC) docsDevServerDhcp: IP address of DHCP server that assigned IP address (DOC) docsDevServerTime: IP address of time server (DOC) docsDevServerTftp: TFTP server for provisioning params (DOC) docsDevServerConfigFile: Config file to be read from TFTP server (DIF) dvbNiuEventPolicy / docsDevEvControl: Controls event logging The DVB object has more enumerations for managing the log size. DOCSIS provides an enumeration to reset event priorities to their factory defaults. (DOC) docsDevEvSyslog: IP address of Syslog server (SIM) dvbNiuEvThrottleAdminStatus / docsDevEvThrottleAdminStatus (SIM) dvbNiuEvThrottleInhibited / docsDevEvThrottleInhibited (SIM) dvbNiuEvThrottleThreshold / docsDevEvThrottleThreshold (SIM) dvbNiuEvThrottleInterval / docsDevEvThrottleInterval (DIF) dvbNiuEventControlTable / docsDevEvControlTable: Event control table Priority values (dvbNiuEventControlPriority/docsDevEvPriority) are the same. Reporting action for DVB (dvbNiuEventControlAction) does not include SYSLOG, but reporting action for DOCSIS (docsDevEvReporting) does include SYSLOG. (DVB) dvbNiuEventTableMaxSize: Max number of entries event log can hold (DIF) dvbNiuEventTable / docsDevEvTable: Event log For the DVB table each event creates a new row, whereas the DOCSIS table allows a single row to represent multiple events of the same nature. The DVB table also allows individual event entries to be deleted. (DIF) dvbNiuDateAndTime / docsDevEvFirstTime + docsDevEvLastTime + docsDevEvCounts Because the DVB event table does not support multiple events per row only one DateAndTime object is required. (SIM) dvbNiuEventType / docsDevEvLevel (SIM) dvbEventDescription / docsDevEvText (DIF) dvbNiuEventCode / docsDevEvId: Code to uniquely identify the type of event The DVB object is a SnmpAdminString with a recommended structure, whereas the DOCSIS object is an Unsigned32. (DVB) dvbNiuEventStatus: RowStatus (DIF) dvdNiuEthFilter + dvbNiuIpFilter / docsDevFilter: Ethernet/LLC and IP filtering Ethernet and IP filtering are optional to implement in DVB (DOC) docsDevFilterLLCUnmatchedAction: Unmatched filter action The DVB behavior is to discard packets if filtering is enabled but a match is not found. (DVB) dvbNiuEthernetFilterEnable: Enables/disables filters, and provides debug feature (DIF) dvbNiuEthernetFilterTable / docsDevFilterLLCTable (SIM) dvbNiuEthernetFilterIndex / docsDevFilterLLCIndex (SIM) dvbNiuEthernetFilterStatus / docsDevFilterLLCStatus (SIM) docsDevFilterLLCIfIndex / dvbNiuEthernetFilterIfIndex (DIF) dvbNiuEthernetFilterEtherType / docsDevFilterLLCProtocolType: Format of protocol field The DVB object enumeration distinguishes Ethernet2 and 802.2 SNAP frames, whereas the DOCSIS object enumeration does not. (SIM) dvbNiuEthernetFilterProtocol / docsDevFilterLLCProtocol (DVB) dvbNiuEthernetFilterAction: Action to be performed if filter match. (SIM) dvbNiuEthernetFilterMatches / docsDevFilterLLCMatches (DOC) docsDevFilterIpDefault: Unmatched filter action The DVB behavior is to discard packets if filtering is enabled but a match is not found. (DVB) dvbNiuIpFilterEnable: Enables/disables filters and provides debug feature. (DIF) dvbNiuIpFilterTable / docsDevFilterIpTable Difference in naming convention and description. With DVB packets are always discarded if there is no matching filter. DVB has no concept of a policy table. (SIM) dvbNiuIpFilterIndex / docsDevFilterIpIndex (SIM) dvbNiuIpFilterStatus / docsDevFilterIpStatus (DVB) dvbNiuIpFilterAssignedby: How the entry was made in the table The DVB MIB combines the DHCP anti-spoofing filters and general filters in a single table. (DIF) dvbNiuIpFilterAction / docsDevFilterIpControl: What action to take on a hit The DVB object has extra different enumerations for TOS, NAT, NAPT as there is no policy table. (SIM) dvbNiuIpFilterIfIndex / docsDevFilterIpIfIndex (SIM) dvbNiuIpFilterDirection / docsDevFilterIpDirection (DOC) docsDevFilterIpBroadcast: Filter applicable to Broadcast/Multicast A single IP filter row can capture all IP broadcast/multicasts with this object, including IP subnet broadcasts (e.g. 10.1.1.255), IP all-subnet broadcasts (255.255.255.255), and IP multicasts (e.g. 224.0.1.1). (SIM) dvbNiuIpFilterSrcAddr / docsDevFilterIpSaddr (SIM) dvbNiuIpFilterSrcMask / docsDevFilterIpSmask (SIM) dvbNiuIpFilterDstAddr / docsDevFilterIpDaddr (SIM) dvbNiuIpFilterDstMask / docsDevFilterIpDmask (SIM) dvbNiuIpFilterProtocol / docsDevFilterIpProtocol (SIM) dvbNiuIpFilterSrcPortLow / docsDevFilterIpSourcePortLow (SIM) dvbNiuIpFilterSrcPortHigh / docsDevFilterIpSourcePortHigh (SIM) dvbNiuIpFilterDstPortLow / docsDevFilterIpDestPortLow (SIM) dvbNiuIpFilterDstPortHigh / docsDevFilterIpDestPortHigh (SIM) dvbNiuIpFilterMatches / docsDevFilterIpMatches (SIM) dvbNiuIpFilterTos / docsDevFilterIpTos (SIM) docsDevFilterIpTosMask / dvbNiuIpFilterTosMask (SIM) dvbNiuIpFilterContinue / docsDevFilterIpContinue (DIF) dvbNiuIpFilterActionPtr / docsDevFilterIpPolicyId: Points to an entry in a table The DVB object points into a table specific to each type of action defined in dvbNiuIpFilterAction. The DOCSIS object points into the policy table. (DOC) docsDevFilterPolicyTable (entire table) (DOC) docsDevFilterPolicyIndex (DOC) docsDevFilterPolicyId (DOC) docsDevFilterPolicyStatus (DOC) docsDevFilterPolicyPtr (SIM) dvbNiuIpTOSMapTable / docsDevFilterTosTable: TOS manipulation table The DVB TOS Mapping table includes a policy ID. (SIM) docsDevFilterTosIndex / dvbNiuIpTosMapIndex (DVB) dvbNiuIpTosMapPolicyId (SIM) docsDevFilterTosStatus / dvbNiuIpTosMapStatus (SIM) docsDevFilterTosAndMask / dvbNiuIpTosMapAndMask (SIM) docsDevFilterTosOrMask / dvbNiuIpTosMapOrMask (DOC) docsDevCpeEnroll: controls population of docsDevFilterCpeTable (DOC) docsDevCpeIpMax: Control number of CPEs allowed to connect behind device (DOC) docsDevCpeTable (entire table): CPE IP address based access control (DVB) dvbNiuNatTable (entire table): Network Address Translation (NAT) table (DVB) dvbNiuNaptAddr: IP address used for NAPT (Network Address and Port Translation) (DVB) dvbNiuNaptTable (entire table): Network Address and Port Translation (NAPT) table Conclusion To consolidate the MIBs into a single cable device MIB would result in a MIB containing three logical components: the common component, the DOCSIS component, and the DVB component. Note that most, if not all, of the objects have been defined in the current DOCSIS Cable Device and/or DVB NIU MIBs. The common component of the merged MIB would contain the following object groups: - the Basic Modem Control group, with objects for modem type/role, date and time, modem reset, modem reset count, serial number, MIB version, and "implementation set", - the Network Management Access Control group (to be replaced with SNMPv3 kickstart), - the Event Logging group, - the Ethernet/LLC Filtering group (with objects for upstream traffic direction), - the IP Filtering group (with objects for upstream traffic direction), - the IP ToS Mapping group, and - the CPE Management group (this may be part of the IP Filtering group). The DOCSIS component of the merged MIB would contain the following object groups: - the DOCSIS Modem Control group, with objects for managing DOCSIS reset, administrative status, operational status, spanning tree control, DHCP/Time of Day/TFTP controls, and SYSLOG control, and - the DOCSIS Software Management group (single image). The DVB component of the merged MIB would contain the following object groups: - the DVB Modem Control group, with objects for managing DVB reset, administrative status, operational status, and Euroloader control, - the DVB Software Management group (multiple images), - the Static Route Table group, - the DHCP Relay group, - the Network Address Translation group, and - the Network Address and Port Translation group. From owner-ipcdn@terayon.com Wed Feb 16 19:36:41 2000 Received: from www.terayon.com (terayon.com [157.22.250.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19117 for ; Wed, 16 Feb 2000 19:36:34 -0500 (EST) Received: from redpine.terayon.com (redpine [157.22.250.5]) by www.terayon.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id QAA13935 for ; Wed, 16 Feb 2000 16:36:17 -0800 (PST) Received: from mail-serv.terayon.com by redpine.terayon.com via smtpd (for mails.terayon.com [157.22.250.1]) with SMTP; 17 Feb 2000 00:36:16 UT Received: from tamarind.terayon.com (tamarind.terayon.com [172.20.0.6]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id QAA06072; Wed, 16 Feb 2000 16:35:51 -0800 (PST) Received: (from root@localhost) by tamarind.terayon.com (8.8.8+Sun/8.8.8) id QAA19983 for ipcdn-outgoing; Wed, 16 Feb 2000 16:34:15 -0800 (PST) Message-Id: <200002170034.TAA26270@funnel.cisco.com> X-Sender: rwoundy@funnel X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 16 Feb 2000 19:38:11 -0500 To: ipcdn@terayon.com From: Rich Woundy Subject: Changes included in the 2/16 BPI MIB Cc: docsis-oss@cablelabs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipcdn@terayon.com Precedence: bulk Reply-To: ipcdn@terayon.com Folks, The last changes in the BPI MIB and internet draft were prompted by comments from Kaz Ozawa, K.Ozawa@CableLabs.com. In this email, I have copied his comments, and described what I did to the internet draft as a result. >One question on docsBpiIpMulticastPrefixLength > >I assume that the PrefixLength makes the mask as follows. > >0 - mask of 0x00000000 >1 - mask of 0x80000000 >8 - mask of 0xff000000 >32 - mask of 0xffffffff > >Then compares { actuall IP Multicast Address AND mask } >and { docsBpiIpMulticastAddress AND mask } > >Is this correct ? I changed the descriptions of docsBpiIpMulticastAddress and docsBpiIpMulticastPrefixLength to make the multicast address and prefix length semantics very clear (I hope). The new description for docsBpiIpMulticastAddress is: "This object represents the IP multicast address (prefix) to be mapped by this row, in conjunction with docsBpiIpMulticastPrefixLength." The new description for docsBpiIpMulticastPrefixLength is: "This object represents the IP multicast address prefix length for this row. The value of this object represents the length in bits of docsBpiIpMulticastAddress for multicast address comparisons, using big-endian ordering. An IP multicast address matches this row if the (docsBpiIpMulticastPrefixLength) most significant bits of the IP multicast address and of the (docsBpiIpMulticastAddress) are identical. This object is similar in usage to an IP address mask. The value 0 corresponds to IP address mask 0.0.0.0, the value 1 corresponds to IP address mask 128.0.0.0, the value 8 corresponds to IP address mask 255.0.0.0, and the value 32 corresponds to IP address mask 255.255.255.255." >section 2.7 >According to CableLabs' definition, >"Data-Over-Cable Service Interface Specifications" >instead of "Data Over Cable Interface Specification" I fixed this as Kaz suggested. >section 3.2, 2nd bullet says; > The Baseline Privacy management interface needs to support > operator configuration of Authorization and TEK Finite State > Machine (FSM) parameters, for performance tuning and security > incident handling. The CMTS MUST support configuring and > viewing all FSM-related parameters, including baseline privacy > status (enabled or disabled), key lifetimes, key grace times, > and state timeout values. The CM MUST support viewing these > parameters where possible. > >I understand that, while the BPI MIB does not support configuring >the baseline privacy status, etc, I think the above paragraph is >a general requirement for OSSI and the above paragraph is fine. >(If the above paragraph is a requirement for the MIB, it may >be better to remove "configuring and".) I changed the offending sentence to say: "The CMTS MUST support viewing (and configuring if possible) all FSM-related parameters, including..." >section 6, References >[18] through [21], the URLs for these documents have been >changed. I think we only be able to specify > http://www.cablemodem.com/ >for all of these 4 documents. I fixed this as Kaz suggested. I forgot about Livelink. :^( >Many objects contain "Note: this object will be read-write >accessible only after....." in their DESCRIPTION. While this is >not a technical problem at all, they can be removed now..... >But I'm not sure. I removed these sentences from various object descriptions, as Kaz suggested. >docsBpiCmTEKEntry >If I understand correctly, the entry is only for unicast and >we should remove "or multicast" from DESCRIPTION. I changed the description of docsBpiCmTEKEntry to: "Each entry contains objects describing the TEK association attributes of one SID. The CM MUST create one entry per unicast SID, regardless of whether the SID was obtained from a Registration Response message, or from an Authorization Reply message." -- Rich From owner-ipcdn@terayon.com Wed Feb 16 19:37:32 2000 Received: from www.terayon.com (terayon.com [157.22.250.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19118 for ; Wed, 16 Feb 2000 19:36:34 -0500 (EST) Received: from redpine.terayon.com (redpine [157.22.250.5]) by www.terayon.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id QAA13938 for ; Wed, 16 Feb 2000 16:36:17 -0800 (PST) Received: from mail-serv.terayon.com by redpine.terayon.com via smtpd (for mails.terayon.com [157.22.250.1]) with SMTP; 17 Feb 2000 00:36:17 UT Received: from tamarind.terayon.com (tamarind.terayon.com [172.20.0.6]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id QAA06109; Wed, 16 Feb 2000 16:35:58 -0800 (PST) Received: (from root@localhost) by tamarind.terayon.com (8.8.8+Sun/8.8.8) id QAA19973 for ipcdn-outgoing; Wed, 16 Feb 2000 16:33:39 -0800 (PST) Message-Id: <200002170033.TAA26206@funnel.cisco.com> X-Sender: rwoundy@funnel X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 16 Feb 2000 19:37:13 -0500 To: ipcdn@terayon.com From: Rich Woundy Subject: The 2/16 BPI MIB Cc: docsis-oss@cablelabs.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_35249115==_" Sender: owner-ipcdn@terayon.com Precedence: bulk Reply-To: ipcdn@terayon.com --=====================_35249115==_ Content-Type: text/plain; charset="us-ascii" Folks, FYI. I am going to submit the attached BPI MIB document as an Internet draft today. Finally! For your compiling convenience, I have also attached the raw MIB file. I will send the last set of changes in another email. -- Rich --=====================_35249115==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="bpimib-021600.txt" DOCS-BPI-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32, IpAddress FROM SNMPv2-SMI DisplayString, MacAddress, RowStatus, TruthValue, DateAndTime FROM SNMPv2-TC OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF ifIndex FROM IF-MIB docsIfMib, docsIfCmServiceId, docsIfCmtsServiceId FROM DOCS-IF-MIB ; docsBpiMIB MODULE-IDENTITY LAST-UPDATED "200002161930Z" ORGANIZATION "IETF IPCDN Working Group" CONTACT-INFO "Rich Woundy Postal: Cisco Systems 250 Apollo Drive Chelmsford, MA 01824 U.S.A. Tel: +1 978 244 8000 E-mail: rwoundy@cisco.com" DESCRIPTION "This is the MIB Module for the DOCSIS Baseline Privacy Interface (BPI) at cable modems (CMs) and cable modem termination systems (CMTSs)." ::= { docsIfMib 5 } docsBpiMIBObjects OBJECT IDENTIFIER ::= { docsBpiMIB 1 } -- Cable Modem Group docsBpiCmObjects OBJECT IDENTIFIER ::= { docsBpiMIBObjects 1 } -- -- The BPI base and authorization table for CMs, indexed by ifIndex -- docsBpiCmBaseTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpiCmBaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the basic and authorization-related Baseline Privacy attributes of each CM MAC interface." ::= { docsBpiCmObjects 1 } docsBpiCmBaseEntry OBJECT-TYPE SYNTAX DocsBpiCmBaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing attributes of one CM MAC interface. An entry in this table exists for each ifEntry with an ifType of docsCableMaclayer(127)." INDEX { ifIndex } ::= { docsBpiCmBaseTable 1 } DocsBpiCmBaseEntry ::= SEQUENCE { docsBpiCmPrivacyEnable TruthValue, docsBpiCmPublicKey OCTET STRING, docsBpiCmAuthState INTEGER, docsBpiCmAuthKeySequenceNumber Integer32, docsBpiCmAuthExpires DateAndTime, docsBpiCmAuthReset TruthValue, docsBpiCmAuthGraceTime Integer32, docsBpiCmTEKGraceTime Integer32, docsBpiCmAuthWaitTimeout Integer32, docsBpiCmReauthWaitTimeout Integer32, docsBpiCmOpWaitTimeout Integer32, docsBpiCmRekeyWaitTimeout Integer32, docsBpiCmAuthRejectWaitTimeout Integer32, docsBpiCmAuthRequests Counter32, docsBpiCmAuthReplies Counter32, docsBpiCmAuthRejects Counter32, docsBpiCmAuthInvalids Counter32, docsBpiCmAuthRejectErrorCode INTEGER, docsBpiCmAuthRejectErrorString DisplayString, docsBpiCmAuthInvalidErrorCode INTEGER, docsBpiCmAuthInvalidErrorString DisplayString } docsBpiCmPrivacyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies whether this CM is provisioned to run Baseline Privacy. This is analogous to the presence (or absence) of the Baseline Privacy Configuration Setting option. The status of each individual SID with respect to Baseline Privacy is captured in the docsBpiCmTEKPrivacyEnable object." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1." ::= { docsBpiCmBaseEntry 1 } docsBpiCmPublicKey OBJECT-TYPE SYNTAX OCTET STRING (SIZE (74 | 106 | 140 | 270)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is a DER-encoded RSAPublicKey ASN.1 type string, as defined in the RSA Encryption Standard (PKCS #1) [22], corresponding to the public key of the CM. The 74, 106, 140, and 270 byte key encoding lengths correspond to 512 bit, 768 bit, 1024 bit, and 2048 public moduli respectively." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.2.4." ::= { docsBpiCmBaseEntry 2 } docsBpiCmAuthState OBJECT-TYPE SYNTAX INTEGER { start(1), authWait(2), authorized(3), reauthWait(4), authRejectWait(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the state of the CM authorization FSM. The start state indicates that FSM is in its initial state." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.1.2.1." ::= { docsBpiCmBaseEntry 3 } docsBpiCmAuthKeySequenceNumber OBJECT-TYPE SYNTAX Integer32 (0..15) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the authorization key sequence number for this FSM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.2 and 4.2.2.10." ::= { docsBpiCmBaseEntry 4 } docsBpiCmAuthExpires OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time when the current authorization for this FSM expires. If the CM does not have an active authorization, then the value is of the expiration date and time of the last active authorization." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.2 and 4.2.2.9." ::= { docsBpiCmBaseEntry 5 } docsBpiCmAuthReset OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to TRUE generates a Reauthorize event in the authorization FSM. Reading this object always returns FALSE." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.1.2.3.4." ::= { docsBpiCmBaseEntry 6 } docsBpiCmAuthGraceTime OBJECT-TYPE SYNTAX Integer32 (1..1800) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the grace time for an authorization key. A CM is expected to start trying to get a new authorization key beginning AuthGraceTime seconds before the authorization key actually expires. The value of this object cannot be changed while the authorization state machine is running." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.3." ::= { docsBpiCmBaseEntry 7 } docsBpiCmTEKGraceTime OBJECT-TYPE SYNTAX Integer32 (1..1800) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the grace time for a TEK. A CM is expected to start trying to get a new TEK beginning TEKGraceTime seconds before the TEK actually expires. The value of this object cannot be changed while the authorization state machine is running." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.6." ::= { docsBpiCmBaseEntry 8 } docsBpiCmAuthWaitTimeout OBJECT-TYPE SYNTAX Integer32 (1..30) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Authorize Wait Timeout. The value of this object cannot be changed while the authorization state machine is running." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.1." ::= { docsBpiCmBaseEntry 9 } docsBpiCmReauthWaitTimeout OBJECT-TYPE SYNTAX Integer32 (1..30) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Reauthorize Wait Timeout in seconds. The value of this object cannot be changed while the authorization state machine is running." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.2." ::= { docsBpiCmBaseEntry 10 } docsBpiCmOpWaitTimeout OBJECT-TYPE SYNTAX Integer32 (1..10) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Operational Wait Timeout in seconds. The value of this object cannot be changed while the authorization state machine is running." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.4." ::= { docsBpiCmBaseEntry 11 } docsBpiCmRekeyWaitTimeout OBJECT-TYPE SYNTAX Integer32 (1..10) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Rekey Wait Timeout in seconds. The value of this object cannot be changed while the authorization state machine is running." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.5." ::= { docsBpiCmBaseEntry 12 } docsBpiCmAuthRejectWaitTimeout OBJECT-TYPE SYNTAX Integer32 (1..600) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Authorization Reject Wait Timeout in seconds. The value of this object cannot be changed while the authorization state machine is running." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.7." ::= { docsBpiCmBaseEntry 13 } docsBpiCmAuthRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CM has transmitted an Authorization Request message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.1." ::= { docsBpiCmBaseEntry 14 } docsBpiCmAuthReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CM has received an Authorization Reply message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.2." ::= { docsBpiCmBaseEntry 15 } docsBpiCmAuthRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CM has received an Authorization Reject message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.3." ::= { docsBpiCmBaseEntry 16 } docsBpiCmAuthInvalids OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CM has received an Authorization Invalid message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.7." ::= { docsBpiCmBaseEntry 17 } docsBpiCmAuthRejectErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), unauthorizedCm(3), unauthorizedSid(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in most recent Authorization Reject message received by the CM. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no Authorization Reject message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.3 and 4.2.2.16." ::= { docsBpiCmBaseEntry 18 } docsBpiCmAuthRejectErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Display-String in most recent Authorization Reject message received by the CM. This is a zero length string if no Authorization Reject message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.3 and 4.2.2.6." ::= { docsBpiCmBaseEntry 19 } docsBpiCmAuthInvalidErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), unauthorizedCm(3), unsolicited(5), invalidKeySequence(6), keyRequestAuthenticationFailure(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in most recent Authorization Invalid message received by the CM. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no Authorization Invalid message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.7 and 4.2.2.16." ::= { docsBpiCmBaseEntry 20 } docsBpiCmAuthInvalidErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Display-String in most recent Authorization Invalid message received by the CM. This is a zero length string if no Authorization Invalid message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.7 and 4.2.2.6." ::= { docsBpiCmBaseEntry 21 } -- -- The CM TEK Table, indexed by ifIndex and SID -- docsBpiCmTEKTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpiCmTEKEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the attributes of each CM Traffic Encryption Key (TEK) association. The CM maintains (no more than) one TEK association per SID per CM MAC interface." ::= { docsBpiCmObjects 2 } docsBpiCmTEKEntry OBJECT-TYPE SYNTAX DocsBpiCmTEKEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing the TEK association attributes of one SID. The CM MUST create one entry per unicast SID, regardless of whether the SID was obtained from a Registration Response message, or from an Authorization Reply message." INDEX { ifIndex, docsIfCmServiceId } ::= { docsBpiCmTEKTable 1 } DocsBpiCmTEKEntry ::= SEQUENCE { docsBpiCmTEKPrivacyEnable TruthValue, docsBpiCmTEKState INTEGER, docsBpiCmTEKExpiresOld DateAndTime, docsBpiCmTEKExpiresNew DateAndTime, docsBpiCmTEKKeyRequests Counter32, docsBpiCmTEKKeyReplies Counter32, docsBpiCmTEKKeyRejects Counter32, docsBpiCmTEKInvalids Counter32, docsBpiCmTEKAuthPends Counter32, docsBpiCmTEKKeyRejectErrorCode INTEGER, docsBpiCmTEKKeyRejectErrorString DisplayString, docsBpiCmTEKInvalidErrorCode INTEGER, docsBpiCmTEKInvalidErrorString DisplayString } docsBpiCmTEKPrivacyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies whether this SID is provisioned to run Baseline Privacy. This is analogous to enabling Baseline Privacy on a provisioned SID using the Class-of-Service Privacy Enable option. Baseline Privacy is not effectively enabled for any SID unless Baseline Privacy is enabled for the CM, which is managed via the docsBpiCmPrivacyEnable object." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.2." ::= { docsBpiCmTEKEntry 1 } docsBpiCmTEKState OBJECT-TYPE SYNTAX INTEGER { start(1), opWait(2), opReauthWait(3), operational(4), rekeyWait(5), rekeyReauthWait(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the state of the indicated TEK FSM. The start(1) state indicates that FSM is in its initial state." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.1.3.1." ::= { docsBpiCmTEKEntry 2 } docsBpiCmTEKExpiresOld OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time for expiration of the immediate predecessor of the most recent TEK for this FSM. If this FSM has only one TEK, then the value is the time of activation of this FSM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.5 and 4.2.2.9." ::= { docsBpiCmTEKEntry 3 } docsBpiCmTEKExpiresNew OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time for expiration of the most recent TEK for this FSM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.5 and 4.2.2.9." ::= { docsBpiCmTEKEntry 4 } docsBpiCmTEKKeyRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CM has transmitted a Key Request message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.4." ::= { docsBpiCmTEKEntry 5 } docsBpiCmTEKKeyReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CM has received a Key Reply message, including a message whose authentication failed." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.5." ::= { docsBpiCmTEKEntry 6 } docsBpiCmTEKKeyRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CM has received a Key Reject message, including a message whose authentication failed." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.6." ::= { docsBpiCmTEKEntry 7 } docsBpiCmTEKInvalids OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CM has received a TEK Invalid message, including a message whose authentication failed." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.8." ::= { docsBpiCmTEKEntry 8 } docsBpiCmTEKAuthPends OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times an Authorization Pending (Auth Pend) event occurred in this FSM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.1.3.3.3." ::= { docsBpiCmTEKEntry 9 } docsBpiCmTEKKeyRejectErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), unauthorizedSid(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in most recent Key Reject message received by the CM. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no Key Reject message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.1.2.6 and 4.2.2.16." ::= { docsBpiCmTEKEntry 10 } docsBpiCmTEKKeyRejectErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Display-String in most recent Key Reject message received by the CM. This is a zero length string if no Key Reject message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.1.2.6 and 4.2.2.6." ::= { docsBpiCmTEKEntry 11 } docsBpiCmTEKInvalidErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), invalidKeySequence(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in most recent TEK Invalid message received by the CM. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no TEK Invalid message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.1.2.8 and 4.2.2.16." ::= { docsBpiCmTEKEntry 12 } docsBpiCmTEKInvalidErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Display-String in most recent TEK Invalid message received by the CM. This is a zero length string if no TEK Invalid message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.1.2.8 and 4.2.2.6." ::= { docsBpiCmTEKEntry 13 } -- Cable Modem Termination System Group docsBpiCmtsObjects OBJECT IDENTIFIER ::= { docsBpiMIBObjects 2 } -- -- The BPI base table for CMTSs, indexed by ifIndex -- docsBpiCmtsBaseTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpiCmtsBaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the basic Baseline Privacy attributes of each CMTS MAC interface." ::= { docsBpiCmtsObjects 1 } docsBpiCmtsBaseEntry OBJECT-TYPE SYNTAX DocsBpiCmtsBaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing attributes of one CMTS MAC interface. An entry in this table exists for each ifEntry with an ifType of docsCableMaclayer(127)." INDEX { ifIndex } ::= { docsBpiCmtsBaseTable 1 } DocsBpiCmtsBaseEntry ::= SEQUENCE { docsBpiCmtsDefaultAuthLifetime Integer32, docsBpiCmtsDefaultTEKLifetime Integer32, -- docsBpiCmtsDefaultAuthGraceTime Integer32, -- docsBpiCmtsDefaultTEKGraceTime Integer32, docsBpiCmtsAuthRequests Counter32, docsBpiCmtsAuthReplies Counter32, docsBpiCmtsAuthRejects Counter32, docsBpiCmtsAuthInvalids Counter32 } docsBpiCmtsDefaultAuthLifetime OBJECT-TYPE SYNTAX Integer32 (1..6048000) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object is the default lifetime, in seconds, the CMTS assigns to a new authorization key." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.2." ::= { docsBpiCmtsBaseEntry 1 } docsBpiCmtsDefaultTEKLifetime OBJECT-TYPE SYNTAX Integer32 (1..604800) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object is the default lifetime, in seconds, the CMTS assigns to a new Traffic Encryption Key (TEK)." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.2." ::= { docsBpiCmtsBaseEntry 2 } -- Note: the following two objects have been removed from this MIB. -- docsBpiCmtsDefaultAuthGraceTime OBJECT-TYPE -- SYNTAX Integer32 (1..1800) -- UNITS "seconds" -- MAX-ACCESS read-write -- STATUS current -- DESCRIPTION -- "Default grace time, in seconds, the CMTS uses for an authorization -- key. This controls how far in advance of authorization key expiration -- that the CMTS is expected to produce the next generation of keying -- material. This value is expected to agree with the Authorization Grace -- Time that the provisioning system provides to CMs." -- ::= { docsBpiCmtsBaseEntry 3 } -- docsBpiCmtsDefaultTEKGraceTime OBJECT-TYPE -- SYNTAX Integer32 (1..1800) -- UNITS "seconds" -- MAX-ACCESS read-write -- STATUS current -- DESCRIPTION -- "Default grace time, in seconds, the CMTS uses for a Traffic -- Encryption Key (TEK). This controls how far in advance of TEK -- expiration that the CMTS is expected to produce the next generation -- of keying material. This value is expected to agree with the TEK Grace -- Time that the provisioning system provides to CMs. Note that this -- object is particularly relevant for multicast SIDs, where multiple -- grace time values cannot be honored." -- ::= { docsBpiCmtsBaseEntry 4 } docsBpiCmtsAuthRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has received an Authorization Request message from any CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.1." ::= { docsBpiCmtsBaseEntry 5 } docsBpiCmtsAuthReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted an Authorization Reply message to any CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.2." ::= { docsBpiCmtsBaseEntry 6 } docsBpiCmtsAuthRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted an Authorization Reject message to any CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.3." ::= { docsBpiCmtsBaseEntry 7 } docsBpiCmtsAuthInvalids OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted an Authorization Invalid message to any CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.7." ::= { docsBpiCmtsBaseEntry 8 } -- -- The CMTS Authorization Table, indexed by ifIndex and CM MAC address -- docsBpiCmtsAuthTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpiCmtsAuthEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the attributes of each CM authorization association. The CMTS maintains one authorization association with each Baseline Privacy-enabled CM on each CMTS MAC interface." ::= { docsBpiCmtsObjects 2 } docsBpiCmtsAuthEntry OBJECT-TYPE SYNTAX DocsBpiCmtsAuthEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing attributes of one authorization association. The CMTS MUST create one entry per CM per MAC interface, based on the receipt of an Authorization Request message, and MUST not delete the entry before the CM authorization permanently expires." INDEX { ifIndex, docsBpiCmtsAuthCmMacAddress } ::= { docsBpiCmtsAuthTable 1 } DocsBpiCmtsAuthEntry ::= SEQUENCE { docsBpiCmtsAuthCmMacAddress MacAddress, docsBpiCmtsAuthCmPublicKey OCTET STRING, docsBpiCmtsAuthCmKeySequenceNumber Integer32, docsBpiCmtsAuthCmExpires DateAndTime, docsBpiCmtsAuthCmLifetime Integer32, docsBpiCmtsAuthCmGraceTime Integer32, docsBpiCmtsAuthCmReset INTEGER, docsBpiCmtsAuthCmRequests Counter32, docsBpiCmtsAuthCmReplies Counter32, docsBpiCmtsAuthCmRejects Counter32, docsBpiCmtsAuthCmInvalids Counter32, docsBpiCmtsAuthRejectErrorCode INTEGER, docsBpiCmtsAuthRejectErrorString DisplayString, docsBpiCmtsAuthInvalidErrorCode INTEGER, docsBpiCmtsAuthInvalidErrorString DisplayString } docsBpiCmtsAuthCmMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is the physical address of the CM to which the authorization association applies." ::= { docsBpiCmtsAuthEntry 1 } docsBpiCmtsAuthCmPublicKey OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 74 | 106 | 140 | 270)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is a DER-encoded RSAPublicKey ASN.1 type string, as defined in the RSA Encryption Standard (PKCS #1) [22], corresponding to the public key of the CM. The 74, 106, 140, and 270 byte key encoding lengths correspond to 512 bit, 768 bit, 1024 bit, and 2048 public moduli respectively. This is a zero-length string if the CMTS does not retain the public key." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.2.4." ::= { docsBpiCmtsAuthEntry 2 } docsBpiCmtsAuthCmKeySequenceNumber OBJECT-TYPE SYNTAX Integer32 (0..15) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the authorization key sequence number for this CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.2 and 4.2.2.10." ::= { docsBpiCmtsAuthEntry 3 } docsBpiCmtsAuthCmExpires OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time when the current authorization for this CM expires. If this CM does not have an active authorization, then the value is of the expiration date and time of the last active authorization." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.2 and 4.2.2.9." ::= { docsBpiCmtsAuthEntry 4 } docsBpiCmtsAuthCmLifetime OBJECT-TYPE SYNTAX Integer32 (1..6048000) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object is the lifetime, in seconds, the CMTS assigns to an authorization key for this CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.2 and Appendix A.2." ::= { docsBpiCmtsAuthEntry 5 } docsBpiCmtsAuthCmGraceTime OBJECT-TYPE SYNTAX Integer32 (1..1800) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the grace time for the authorization key in seconds. The CM is expected to start trying to get a new authorization key beginning AuthGraceTime seconds before the authorization key actually expires." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.3." ::= { docsBpiCmtsAuthEntry 6 } docsBpiCmtsAuthCmReset OBJECT-TYPE SYNTAX INTEGER { noResetRequested(1), invalidateAuth(2), sendAuthInvalid(3), invalidateTeks(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to invalidateAuth(2) causes the CMTS to invalidate the current CM authorization key, but not to transmit an Authorization Invalid message nor to invalidate unicast TEKs. Setting this object to sendAuthInvalid(3) causes the CMTS to invalidate the current CM authorization key, and to transmit an Authorization Invalid message to the CM, but not to invalidate unicast TEKs. Setting this object to invalidateTeks(4) causes the CMTS to invalidate the current CM authorization key, to transmit an Authorization Invalid message to the CM, and to invalidate all unicast TEKs associated with this CM authorization. Reading this object returns the most-recently-set value of this object, or returns noResetRequested(1) if the object has not been set since the last CMTS reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.1.2.3.4, 4.1.2.3.5, and 4.1.3.3.5." ::= { docsBpiCmtsAuthEntry 7 } docsBpiCmtsAuthCmRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has received an Authorization Request message from this CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.1." ::= { docsBpiCmtsAuthEntry 8 } docsBpiCmtsAuthCmReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted an Authorization Reply message to this CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.2." ::= { docsBpiCmtsAuthEntry 9 } docsBpiCmtsAuthCmRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted an Authorization Reject message to this CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.3." ::= { docsBpiCmtsAuthEntry 10 } docsBpiCmtsAuthCmInvalids OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted an Authorization Invalid message to this CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.7." ::= { docsBpiCmtsAuthEntry 11 } docsBpiCmtsAuthRejectErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), unauthorizedCm(3), unauthorizedSid(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in most recent Authorization Reject message transmitted to the CM. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no Authorization Reject message has been transmitted to the CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.3 and 4.2.2.16." ::= { docsBpiCmtsAuthEntry 12 } docsBpiCmtsAuthRejectErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Display-String in most recent Authorization Reject message transmitted to the CM. This is a zero length string if no Authorization Reject message has been transmitted to the CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.3 and 4.2.2.6." ::= { docsBpiCmtsAuthEntry 13 } docsBpiCmtsAuthInvalidErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), unauthorizedCm(3), unsolicited(5), invalidKeySequence(6), keyRequestAuthenticationFailure(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in most recent Authorization Invalid message transmitted to the CM. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no Authorization Invalid message has been transmitted to the CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.7 and 4.2.2.16." ::= { docsBpiCmtsAuthEntry 14 } docsBpiCmtsAuthInvalidErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Display-String in most recent Authorization Invalid message transmitted to the CM. This is a zero length string if no Authorization Invalid message has been transmitted to the CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.7 and 4.2.2.6." ::= { docsBpiCmtsAuthEntry 15 } -- -- The CMTS TEK Table, indexed by ifIndex and SID -- docsBpiCmtsTEKTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpiCmtsTEKEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the attributes of each CM Traffic Encryption Key (TEK) association. The CMTS maintains one TEK association per BPI SID on each CMTS MAC interface." ::= { docsBpiCmtsObjects 3 } docsBpiCmtsTEKEntry OBJECT-TYPE SYNTAX DocsBpiCmtsTEKEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing attributes of one TEK association on a particular CMTS MAC interface. The CMTS MUST create one entry per SID per MAC interface, based on the receipt of an Key Request message, and MUST not delete the entry before the CM authorization for the SID permanently expires." INDEX { ifIndex, docsIfCmtsServiceId } ::= { docsBpiCmtsTEKTable 1 } DocsBpiCmtsTEKEntry ::= SEQUENCE { docsBpiCmtsTEKLifetime Integer32, docsBpiCmtsTEKGraceTime Integer32, docsBpiCmtsTEKExpiresOld DateAndTime, docsBpiCmtsTEKExpiresNew DateAndTime, docsBpiCmtsTEKReset TruthValue, docsBpiCmtsKeyRequests Counter32, docsBpiCmtsKeyReplies Counter32, docsBpiCmtsKeyRejects Counter32, docsBpiCmtsTEKInvalids Counter32, docsBpiCmtsKeyRejectErrorCode INTEGER, docsBpiCmtsKeyRejectErrorString DisplayString, docsBpiCmtsTEKInvalidErrorCode INTEGER, docsBpiCmtsTEKInvalidErrorString DisplayString } docsBpiCmtsTEKLifetime OBJECT-TYPE SYNTAX Integer32 (1..604800) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object is the lifetime, in seconds, the CMTS assigns to keys for this TEK association." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.5 and Appendix A.2." ::= { docsBpiCmtsTEKEntry 1 } docsBpiCmtsTEKGraceTime OBJECT-TYPE SYNTAX Integer32 (1..1800) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the grace time for the TEK in seconds. The CM is expected to start trying to get a new TEK beginning TEKGraceTime seconds before the TEK actually expires." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.6." ::= { docsBpiCmtsTEKEntry 2 } docsBpiCmtsTEKExpiresOld OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time for expiration of the immediate predecessor of the most recent TEK for this FSM. If this FSM has only one TEK, then the value is the time of activation of this FSM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.5 and 4.2.2.9." ::= { docsBpiCmtsTEKEntry 3 } docsBpiCmtsTEKExpiresNew OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time for expiration of the most recent TEK for this FSM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.5 and 4.2.2.9." ::= { docsBpiCmtsTEKEntry 4 } docsBpiCmtsTEKReset OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to TRUE causes the CMTS to invalidate the current active TEK(s) (plural due to key transition periods), and to generate a new TEK for the associated SID; the CMTS MAY also generate an unsolicited TEK Invalid message, to optimize the TEK synchronization between the CMTS and the CM. Reading this object always returns FALSE." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.1.3.3.5." ::= { docsBpiCmtsTEKEntry 5 } docsBpiCmtsKeyRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has received a Key Request message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.4." ::= { docsBpiCmtsTEKEntry 6 } docsBpiCmtsKeyReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted a Key Reply message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.5." ::= { docsBpiCmtsTEKEntry 7 } docsBpiCmtsKeyRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted a Key Reject message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.6." ::= { docsBpiCmtsTEKEntry 8 } docsBpiCmtsTEKInvalids OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted a TEK Invalid message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.8." ::= { docsBpiCmtsTEKEntry 9 } docsBpiCmtsKeyRejectErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), unauthorizedSid(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in the most recent Key Reject message sent in response to a Key Request for this BPI SID. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no Key Reject message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.6 and 4.2.2.16." ::= { docsBpiCmtsTEKEntry 10 } docsBpiCmtsKeyRejectErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Display-String in the most recent Key Reject message sent in response to a Key Request for this BPI SID. This is a zero length string if no Key Reject message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.6 and 4.2.2.6." ::= { docsBpiCmtsTEKEntry 11 } docsBpiCmtsTEKInvalidErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), invalidKeySequence(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in the most recent TEK Invalid message sent in association with this BPI SID. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no TEK Invalid message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.8 and 4.2.2.16." ::= { docsBpiCmtsTEKEntry 12 } docsBpiCmtsTEKInvalidErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Display-String in the most recent TEK Invalid message sent in association with this BPI SID. This is a zero length string if no TEK Invalid message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.8 and 4.2.2.6." ::= { docsBpiCmtsTEKEntry 13 } -- -- The CMTS Multicast Control Group -- docsBpiMulticastControl OBJECT IDENTIFIER ::= { docsBpiCmtsObjects 4 } -- -- The CMTS IP Multicast Mapping Table, indexed by IP multicast -- address and prefix, and by ifindex -- docsBpiIpMulticastMapTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpiIpMulticastMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the mapping of IP multicast address prefixes to multicast SIDs on each CMTS MAC interface." ::= { docsBpiMulticastControl 1 } docsBpiIpMulticastMapEntry OBJECT-TYPE SYNTAX DocsBpiIpMulticastMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing the mapping of one IP multicast address prefix to one multicast SID on one CMTS MAC interface. The CMTS uses the mapping when forwarding downstream IP multicast traffic." INDEX { ifIndex, docsBpiIpMulticastAddress, docsBpiIpMulticastPrefixLength } ::= { docsBpiIpMulticastMapTable 1 } DocsBpiIpMulticastMapEntry ::= SEQUENCE { docsBpiIpMulticastAddress IpAddress, docsBpiIpMulticastPrefixLength Integer32, docsBpiIpMulticastServiceId Integer32, docsBpiIpMulticastMapControl RowStatus } docsBpiIpMulticastAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the IP multicast address (prefix) to be mapped by this row, in conjunction with docsBpiIpMulticastPrefixLength." ::= { docsBpiIpMulticastMapEntry 1 } docsBpiIpMulticastPrefixLength OBJECT-TYPE SYNTAX Integer32 (0..32) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the IP multicast address prefix length for this row. The value of this object represents the length in bits of docsBpiIpMulticastAddress for multicast address comparisons, using big-endian ordering. An IP multicast address matches this row if the (docsBpiIpMulticastPrefixLength) most significant bits of the IP multicast address and of the (docsBpiIpMulticastAddress) are identical. This object is similar in usage to an IP address mask. The value 0 corresponds to IP address mask 0.0.0.0, the value 1 corresponds to IP address mask 128.0.0.0, the value 8 corresponds to IP address mask 255.0.0.0, and the value 32 corresponds to IP address mask 255.255.255.255." ::= { docsBpiIpMulticastMapEntry 2 } docsBpiIpMulticastServiceId OBJECT-TYPE SYNTAX Integer32 (8192..16368) MAX-ACCESS read-create STATUS current DESCRIPTION "This object represents the multicast SID to be used in this IP multicast address prefix mapping entry." -- DEFVAL is an unused multicast SID value chosen by CMTS. ::= { docsBpiIpMulticastMapEntry 3 } docsBpiIpMulticastMapControl OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls and reflects the IP multicast address prefix mapping entry." ::= { docsBpiIpMulticastMapEntry 4 } -- -- The CMTS Multicast SID Authorization Table, indexed by ifIndex by -- multicast SID by CM MAC address -- docsBpiMulticastAuthTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpiMulticastAuthEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the multicast SID authorization for each CM on each CMTS MAC interface." ::= { docsBpiMulticastControl 2 } docsBpiMulticastAuthEntry OBJECT-TYPE SYNTAX DocsBpiMulticastAuthEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing the key authorization of one cable modem for one multicast SID for one CMTS MAC interface." INDEX { ifIndex, docsBpiMulticastServiceId, docsBpiMulticastCmMacAddress } ::= { docsBpiMulticastAuthTable 1 } DocsBpiMulticastAuthEntry ::= SEQUENCE { docsBpiMulticastServiceId Integer32, docsBpiMulticastCmMacAddress MacAddress, docsBpiMulticastAuthControl RowStatus } docsBpiMulticastServiceId OBJECT-TYPE SYNTAX Integer32 (8192..16368) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the multicast SID for authorization." ::= { docsBpiMulticastAuthEntry 1 } docsBpiMulticastCmMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the MAC address of the CM to which the multicast SID authorization applies." ::= { docsBpiMulticastAuthEntry 2 } docsBpiMulticastAuthControl OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls and reflects the CM authorization for each multicast SID." ::= { docsBpiMulticastAuthEntry 3 } -- -- The BPI MIB Conformance Statements (with a placeholder for -- notifications) -- docsBpiNotification OBJECT IDENTIFIER ::= { docsBpiMIB 2 } docsBpiConformance OBJECT IDENTIFIER ::= { docsBpiMIB 3 } docsBpiCompliances OBJECT IDENTIFIER ::= { docsBpiConformance 1 } docsBpiGroups OBJECT IDENTIFIER ::= { docsBpiConformance 2 } docsBpiBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "This is the compliance statement for devices which implement the DOCSIS Baseline Privacy Interface." MODULE -- docsBpiMIB -- conditionally mandatory group GROUP docsBpiCmGroup DESCRIPTION "This group is implemented only in CMs, not in CMTSs." -- conditionally mandatory group GROUP docsBpiCmtsGroup DESCRIPTION "This group is implemented only in CMTSs, not in CMs." -- relaxation on mandatory range (unnecessary since object is read-only) -- OBJECT docsBpiCmAuthGraceTime -- SYNTAX Integer32 (300..1800) -- DESCRIPTION -- "The refined range corresponds to the minimum and maximum values in -- operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range (unnecessary since object is read-only) -- OBJECT docsBpiCmTEKGraceTime -- SYNTAX Integer32 (300..1800) -- DESCRIPTION -- "The refined range corresponds to the minimum and maximum values in -- operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range OBJECT docsBpiCmtsDefaultAuthLifetime SYNTAX Integer32 (86400..6048000) DESCRIPTION "The refined range corresponds to the minimum and maximum values in operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range OBJECT docsBpiCmtsDefaultTEKLifetime SYNTAX Integer32 (1800..604800) DESCRIPTION "The refined range corresponds to the minimum and maximum values in operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range (object removed from MIB) -- OBJECT docsBpiCmtsDefaultAuthGraceTime -- SYNTAX INTEGER (300..1800) -- DESCRIPTION -- "The refined range corresponds to the minimum and maximum values in -- operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range (object removed from MIB) -- OBJECT docsBpiCmtsDefaultTEKGraceTime -- SYNTAX INTEGER (300..1800) -- DESCRIPTION -- "The refined range corresponds to the minimum and maximum values in -- operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range OBJECT docsBpiCmtsAuthCmLifetime SYNTAX Integer32 (86400..6048000) DESCRIPTION "The refined range corresponds to the minimum and maximum values in operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range (unnecessary since object is read-only) -- OBJECT docsBpiCmtsAuthCmGraceTime -- SYNTAX Integer32 (300..1800) -- DESCRIPTION -- "The refined range corresponds to the minimum and maximum values in -- operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range OBJECT docsBpiCmtsTEKLifetime SYNTAX Integer32 (1800..604800) DESCRIPTION "The refined range corresponds to the minimum and maximum values in operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range (unnecessary since object is read-only) -- OBJECT docsBpiCmtsTEKGraceTime -- SYNTAX Integer32 (300..1800) -- DESCRIPTION -- "The refined range corresponds to the minimum and maximum values in -- operational networks, according to Appendix A.2 in [18]." ::= { docsBpiCompliances 1 } docsBpiCmGroup OBJECT-GROUP OBJECTS { docsBpiCmPrivacyEnable, docsBpiCmPublicKey, docsBpiCmAuthState, docsBpiCmAuthKeySequenceNumber, docsBpiCmAuthExpires, docsBpiCmAuthReset, docsBpiCmAuthGraceTime, docsBpiCmTEKGraceTime, docsBpiCmAuthWaitTimeout, docsBpiCmReauthWaitTimeout, docsBpiCmOpWaitTimeout, docsBpiCmRekeyWaitTimeout, docsBpiCmAuthRejectWaitTimeout, docsBpiCmAuthRequests, docsBpiCmAuthReplies, docsBpiCmAuthRejects, docsBpiCmAuthInvalids, docsBpiCmAuthRejectErrorCode, docsBpiCmAuthRejectErrorString, docsBpiCmAuthInvalidErrorCode, docsBpiCmAuthInvalidErrorString, docsBpiCmTEKPrivacyEnable, docsBpiCmTEKState, docsBpiCmTEKExpiresOld, docsBpiCmTEKExpiresNew, docsBpiCmTEKKeyRequests, docsBpiCmTEKKeyReplies, docsBpiCmTEKKeyRejects, docsBpiCmTEKInvalids, docsBpiCmTEKAuthPends, docsBpiCmTEKKeyRejectErrorCode, docsBpiCmTEKKeyRejectErrorString, docsBpiCmTEKInvalidErrorCode, docsBpiCmTEKInvalidErrorString } STATUS current DESCRIPTION "This collection of objects provides CM BPI status and control." ::= { docsBpiGroups 1 } docsBpiCmtsGroup OBJECT-GROUP OBJECTS { docsBpiCmtsDefaultAuthLifetime, docsBpiCmtsDefaultTEKLifetime, -- docsBpiCmtsDefaultAuthGraceTime, -- docsBpiCmtsDefaultTEKGraceTime, docsBpiCmtsAuthRequests, docsBpiCmtsAuthReplies, docsBpiCmtsAuthRejects, docsBpiCmtsAuthInvalids, docsBpiCmtsAuthCmPublicKey, docsBpiCmtsAuthCmKeySequenceNumber, docsBpiCmtsAuthCmExpires, docsBpiCmtsAuthCmLifetime, docsBpiCmtsAuthCmGraceTime, docsBpiCmtsAuthCmReset, docsBpiCmtsAuthCmRequests, docsBpiCmtsAuthCmReplies, docsBpiCmtsAuthCmRejects, docsBpiCmtsAuthCmInvalids, docsBpiCmtsAuthRejectErrorCode, docsBpiCmtsAuthRejectErrorString, docsBpiCmtsAuthInvalidErrorCode, docsBpiCmtsAuthInvalidErrorString, docsBpiCmtsTEKLifetime, docsBpiCmtsTEKGraceTime, docsBpiCmtsTEKExpiresOld, docsBpiCmtsTEKExpiresNew, docsBpiCmtsTEKReset, docsBpiCmtsKeyRequests, docsBpiCmtsKeyReplies, docsBpiCmtsKeyRejects, docsBpiCmtsTEKInvalids, docsBpiCmtsKeyRejectErrorCode, docsBpiCmtsKeyRejectErrorString, docsBpiCmtsTEKInvalidErrorCode, docsBpiCmtsTEKInvalidErrorString, docsBpiIpMulticastServiceId, docsBpiIpMulticastMapControl, docsBpiMulticastAuthControl } STATUS current DESCRIPTION "This collection of objects provides CMTS BPI status and control." ::= { docsBpiGroups 2 } END --=====================_35249115==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="bpi-id-021600.txt" Internet Draft R. Woundy IPCDN Working Group Cisco Systems draft-ietf-ipcdn-mcns-bpi-mib-01.txt Expires: 16 August 2000 Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based management of the Baseline Privacy Interface, which provides data privacy for DOCSIS 1.0 compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Radio Frequency Interface MIB, RFC 2670. This memo specifies a MIB module in a manner that is compliant to the SNMPv2 SMI. The set of objects is consistent with the SNMP framework and existing SNMP standards. This memo does not specify a standard for the Internet community. Expires August 2000 [Page 1] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@terayon.com and/or the author. Table of Contents 1 The SNMP Management Framework ................................... 2 2 Glossary ........................................................ 3 2.1 Authorization key ............................................. 3 2.2 BPI ........................................................... 3 2.3 BPI+ .......................................................... 4 2.4 CATV .......................................................... 4 2.5 CM ............................................................ 4 2.6 CMTS .......................................................... 4 2.7 DOCSIS ........................................................ 4 2.8 Downstream .................................................... 4 2.9 Head-end ...................................................... 4 2.10 MAC Packet ................................................... 4 2.11 MCNS ......................................................... 4 2.12 RF ........................................................... 5 2.13 SID .......................................................... 5 2.14 TEK .......................................................... 5 2.15 Upstream ..................................................... 5 3 Overview ........................................................ 5 3.1 Structure of the MIB .......................................... 5 3.2 Management requirements ....................................... 6 4 Definitions ..................................................... 7 5 Acknowledgments ................................................ 39 6 References ..................................................... 39 7 Security Considerations ........................................ 41 8 Intellectual Property .......................................... 42 9 Author's Address ............................................... 43 10 Full Copyright Statement ...................................... 43 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7]. Expires August 2000 [Page 2] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. Glossary The terms in this document are derived either from normal cable system usage, or from the documents associated with the Data Over Cable Service Interface Specification process. 2.1. Authorization key A key used to derive a key encryption key (used to encrypt TEKs), and to derive message authentication keys. When the CMTS communicates the authorization key to the CM, it encrypts the authorization key using the RSA public key of the CM [22]. 2.2. BPI - Baseline Privacy Interface Expires August 2000 [Page 3] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 A term referring to the DOCSIS specification [18] for enabling simple data privacy in the DOCSIS 1.0 system. Management of the BPI is the focus of this document. 2.3. BPI+ - Baseline Privacy Plus Interface A term referring to the DOCSIS specification [21] for enabling CM authentication and data privacy in the DOCSIS 1.1 system. Management of the BPI+ is not addressed in this document. 2.4. CATV Originally "Community Antenna Television", now used to refer to any cable or hybrid fiber and cable system used to deliver video signals to a community. 2.5. CM - Cable Modem A CM acts as a "slave" station in a DOCSIS compliant cable data system. 2.6. CMTS - Cable Modem Termination System A generic term covering a cable bridge or cable router in a head-end. A CMTS acts as the master station in a DOCSIS compliant cable data system. It is the only station that transmits downstream, and it controls the scheduling of upstream transmissions by its associated CMs. 2.7. DOCSIS "Data-Over-Cable Service Interface Specifications". A term referring to the ITU-T J.112 Annex B standard for cable modem systems [19]. 2.8. Downstream The direction from the head-end towards the subscriber. 2.9. Head-end The origination point in most cable systems of the subscriber video signals. Generally also the location of the CMTS equipment. 2.10. MAC Packet A DOCSIS PDU. 2.11. MCNS Expires August 2000 [Page 4] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 "Multimedia Cable Network System". Generally replaced in usage by DOCSIS. 2.12. RF Radio Frequency. 2.13 SID Service ID. The SID identifies a particular upstream bandwidth allocation and class-of-service management for DOCSIS, and identifies a particular bidirectional security association for BPI. 2.14. TEK - Traffic Encryption Key Traffic Encryption Key, which is used for DES encryption of upstream and downstream traffic. When the CMTS communicates the TEK to the CM, it encrypts the TEK using the key encryption key derived from the authorization key. 2.15. Upstream The direction from the subscriber towards the head-end. 3. Overview This MIB provides a set of objects required for the management of the Baseline Privacy Interface for DOCSIS compliant Cable Modems (CMs) and Cable Modem Termination Systems (CMTSs). This MIB specification is derived from the DOCSIS Baseline Privacy Interface specification [18], which is an extension to the DOCSIS Radio Frequency Interface specification [19]. Please note that this MIB specification is not sufficient for the management of the DOCSIS Baseline Privacy Plus Interface specification [21]. The working group expects to issue a MIB for the management of BPI+ at a later time. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [23]. 3.1. Structure of the MIB This MIB consists of one group of CM-only objects (docsBpiCmGroup), and one group of CMTS-only objects (docsBpiCmtsGroup). The CM-only objects are organized into two tables: Expires August 2000 [Page 5] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 o The docsBpiCmBaseTable contains objects for managing basic Baseline Privacy parameters and counters, and for managing the Authorization finite state machine. o The docsBpiCmTEKTable contains objects for managing the Traffic Encryption Key (TEK) finite state machine per SID. The CMTS-only objects are organized into four sub-groups: o The docsBpiCmtsBaseTable contains objects for managing basic Baseline Privacy parameters and counters. o The docsBpiCmtsAuthTable contains objects for managing the Authorization association information per cable modem. o The docsBpiCmtsTEKTable contains objects for managing the TEK association information per SID. o The docsBpiMulticastControl consists of two tables. The docsBpiIpMulticastMapTable controls the mapping of downstream IP multicast data traffic to downstream multicast SID values. The docsBpiMulticastAuthTable controls which CMs are authorized to receive downstream traffic transmitted over particular multicast SIDs; a CM will receive TEKs corresponding to the multicast SIDs for which it is authorized. The combination of these two tables will limit the distribution of downstream IP multicast data traffic to authorized CMs. 3.2. Management requirements The Baseline Privacy Interface specification is documented in [18], and is an extension to the Radio Frequency Interface specification documented in [19]. In addition to the explicit requirements in this specification, the CM and CMTS enabled for Baseline Privacy MUST support all applicable DOCSIS and IETF requirements and MIB objects. Specifications that identify relevant requirements and MIB objects include the IETF Radio Frequency MIB [16], the IETF Cable Device MIB [17], and the DOCSIS OSSI Specification [20]. The explicit management requirements of the Baseline Privacy Interface, which motivate the development of the MIB in this document, are detailed below: o The CM and CMTS MUST support viewing relevant RSA public keys, for future subscriber authentication applications. o The Baseline Privacy management interface needs to support operator configuration of Authorization and TEK Finite State Expires August 2000 [Page 6] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 Machine (FSM) parameters, for performance tuning and security incident handling. The CMTS MUST support viewing (and configuring if possible) all FSM-related parameters, including baseline privacy status (enabled or disabled), key lifetimes, key grace times, and state timeout values. The CM MUST support viewing these parameters where possible. o The management interface needs to support operator analysis and override of FSM behavior, for fault management, subscriber service de-provisioning, and security incident handling. The CM MUST support viewing the current FSM states. The CM and CMTS MUST support viewing message error codes and message error strings, and counters for invalid KEK and TEK events, for key expirations and renewals, and for duplicate messages. The CM and CMTS MUST support viewing current authorization key sequence numbers and key expiration times for failure diagnosis. o The management interface needs to support dynamic control of the distribution of IP multicast data traffic. This control includes forwarding IP multicast traffic to the correct multicast group (SID), and managing the membership lists of each multicast group (SID). The CMTS MUST support configuring and viewing all IP multicast forwarding state, and all multicast group memberships, within the MAC domains of the CMTS. 4. Definitions DOCS-BPI-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32, IpAddress FROM SNMPv2-SMI DisplayString, MacAddress, RowStatus, TruthValue, DateAndTime FROM SNMPv2-TC OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF ifIndex FROM IF-MIB docsIfMib, docsIfCmServiceId, docsIfCmtsServiceId FROM DOCS-IF-MIB ; docsBpiMIB MODULE-IDENTITY LAST-UPDATED "200002161930Z" ORGANIZATION "IETF IPCDN Working Group" CONTACT-INFO "Rich Woundy Postal: Cisco Systems Expires August 2000 [Page 7] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 250 Apollo Drive Chelmsford, MA 01824 U.S.A. Tel: +1 978 244 8000 E-mail: rwoundy@cisco.com" DESCRIPTION "This is the MIB Module for the DOCSIS Baseline Privacy Interface (BPI) at cable modems (CMs) and cable modem termination systems (CMTSs)." ::= { docsIfMib 5 } docsBpiMIBObjects OBJECT IDENTIFIER ::= { docsBpiMIB 1 } -- Cable Modem Group docsBpiCmObjects OBJECT IDENTIFIER ::= { docsBpiMIBObjects 1 } -- -- The BPI base and authorization table for CMs, indexed by ifIndex -- docsBpiCmBaseTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpiCmBaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the basic and authorization-related Baseline Privacy attributes of each CM MAC interface." ::= { docsBpiCmObjects 1 } docsBpiCmBaseEntry OBJECT-TYPE SYNTAX DocsBpiCmBaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing attributes of one CM MAC interface. An entry in this table exists for each ifEntry with an ifType of docsCableMaclayer(127)." INDEX { ifIndex } ::= { docsBpiCmBaseTable 1 } DocsBpiCmBaseEntry ::= SEQUENCE { docsBpiCmPrivacyEnable TruthValue, docsBpiCmPublicKey OCTET STRING, docsBpiCmAuthState INTEGER, docsBpiCmAuthKeySequenceNumber Integer32, docsBpiCmAuthExpires DateAndTime, docsBpiCmAuthReset TruthValue, Expires August 2000 [Page 8] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 docsBpiCmAuthGraceTime Integer32, docsBpiCmTEKGraceTime Integer32, docsBpiCmAuthWaitTimeout Integer32, docsBpiCmReauthWaitTimeout Integer32, docsBpiCmOpWaitTimeout Integer32, docsBpiCmRekeyWaitTimeout Integer32, docsBpiCmAuthRejectWaitTimeout Integer32, docsBpiCmAuthRequests Counter32, docsBpiCmAuthReplies Counter32, docsBpiCmAuthRejects Counter32, docsBpiCmAuthInvalids Counter32, docsBpiCmAuthRejectErrorCode INTEGER, docsBpiCmAuthRejectErrorString DisplayString, docsBpiCmAuthInvalidErrorCode INTEGER, docsBpiCmAuthInvalidErrorString DisplayString } docsBpiCmPrivacyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies whether this CM is provisioned to run Baseline Privacy. This is analogous to the presence (or absence) of the Baseline Privacy Configuration Setting option. The status of each individual SID with respect to Baseline Privacy is captured in the docsBpiCmTEKPrivacyEnable object." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1." ::= { docsBpiCmBaseEntry 1 } docsBpiCmPublicKey OBJECT-TYPE SYNTAX OCTET STRING (SIZE (74 | 106 | 140 | 270)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is a DER-encoded RSAPublicKey ASN.1 type string, as defined in the RSA Encryption Standard (PKCS #1) [22], corresponding to the public key of the CM. The 74, 106, 140, and 270 byte key encoding lengths correspond to 512 bit, 768 bit, 1024 bit, and 2048 public moduli respectively." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.2.4." ::= { docsBpiCmBaseEntry 2 } docsBpiCmAuthState OBJECT-TYPE SYNTAX INTEGER { start(1), Expires August 2000 [Page 9] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 authWait(2), authorized(3), reauthWait(4), authRejectWait(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the state of the CM authorization FSM. The start state indicates that FSM is in its initial state." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.1.2.1." ::= { docsBpiCmBaseEntry 3 } docsBpiCmAuthKeySequenceNumber OBJECT-TYPE SYNTAX Integer32 (0..15) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the authorization key sequence number for this FSM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.2 and 4.2.2.10." ::= { docsBpiCmBaseEntry 4 } docsBpiCmAuthExpires OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time when the current authorization for this FSM expires. If the CM does not have an active authorization, then the value is of the expiration date and time of the last active authorization." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.2 and 4.2.2.9." ::= { docsBpiCmBaseEntry 5 } docsBpiCmAuthReset OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to TRUE generates a Reauthorize event in the authorization FSM. Reading this object always returns FALSE." REFERENCE Expires August 2000 [Page 10] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 "DOCSIS Baseline Privacy Interface Specification, Section 4.1.2.3.4." ::= { docsBpiCmBaseEntry 6 } docsBpiCmAuthGraceTime OBJECT-TYPE SYNTAX Integer32 (1..1800) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the grace time for an authorization key. A CM is expected to start trying to get a new authorization key beginning AuthGraceTime seconds before the authorization key actually expires. The value of this object cannot be changed while the authorization state machine is running." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.3." ::= { docsBpiCmBaseEntry 7 } docsBpiCmTEKGraceTime OBJECT-TYPE SYNTAX Integer32 (1..1800) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the grace time for a TEK. A CM is expected to start trying to get a new TEK beginning TEKGraceTime seconds before the TEK actually expires. The value of this object cannot be changed while the authorization state machine is running." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.6." ::= { docsBpiCmBaseEntry 8 } docsBpiCmAuthWaitTimeout OBJECT-TYPE SYNTAX Integer32 (1..30) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Authorize Wait Timeout. The value of this object cannot be changed while the authorization state machine is running." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.1." ::= { docsBpiCmBaseEntry 9 } docsBpiCmReauthWaitTimeout OBJECT-TYPE SYNTAX Integer32 (1..30) UNITS "seconds" Expires August 2000 [Page 11] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Reauthorize Wait Timeout in seconds. The value of this object cannot be changed while the authorization state machine is running." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.2." ::= { docsBpiCmBaseEntry 10 } docsBpiCmOpWaitTimeout OBJECT-TYPE SYNTAX Integer32 (1..10) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Operational Wait Timeout in seconds. The value of this object cannot be changed while the authorization state machine is running." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.4." ::= { docsBpiCmBaseEntry 11 } docsBpiCmRekeyWaitTimeout OBJECT-TYPE SYNTAX Integer32 (1..10) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Rekey Wait Timeout in seconds. The value of this object cannot be changed while the authorization state machine is running." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.5." ::= { docsBpiCmBaseEntry 12 } docsBpiCmAuthRejectWaitTimeout OBJECT-TYPE SYNTAX Integer32 (1..600) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Authorization Reject Wait Timeout in seconds. The value of this object cannot be changed while the authorization state machine is running." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.7." ::= { docsBpiCmBaseEntry 13 } Expires August 2000 [Page 12] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 docsBpiCmAuthRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CM has transmitted an Authorization Request message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.1." ::= { docsBpiCmBaseEntry 14 } docsBpiCmAuthReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CM has received an Authorization Reply message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.2." ::= { docsBpiCmBaseEntry 15 } docsBpiCmAuthRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CM has received an Authorization Reject message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.3." ::= { docsBpiCmBaseEntry 16 } docsBpiCmAuthInvalids OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CM has received an Authorization Invalid message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.7." ::= { docsBpiCmBaseEntry 17 } docsBpiCmAuthRejectErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), Expires August 2000 [Page 13] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 unauthorizedCm(3), unauthorizedSid(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in most recent Authorization Reject message received by the CM. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no Authorization Reject message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.3 and 4.2.2.16." ::= { docsBpiCmBaseEntry 18 } docsBpiCmAuthRejectErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Display-String in most recent Authorization Reject message received by the CM. This is a zero length string if no Authorization Reject message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.3 and 4.2.2.6." ::= { docsBpiCmBaseEntry 19 } docsBpiCmAuthInvalidErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), unauthorizedCm(3), unsolicited(5), invalidKeySequence(6), keyRequestAuthenticationFailure(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in most recent Authorization Invalid message received by the CM. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no Authorization Invalid message has been received since reboot." REFERENCE Expires August 2000 [Page 14] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.7 and 4.2.2.16." ::= { docsBpiCmBaseEntry 20 } docsBpiCmAuthInvalidErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Display-String in most recent Authorization Invalid message received by the CM. This is a zero length string if no Authorization Invalid message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.7 and 4.2.2.6." ::= { docsBpiCmBaseEntry 21 } -- -- The CM TEK Table, indexed by ifIndex and SID -- docsBpiCmTEKTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpiCmTEKEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the attributes of each CM Traffic Encryption Key (TEK) association. The CM maintains (no more than) one TEK association per SID per CM MAC interface." ::= { docsBpiCmObjects 2 } docsBpiCmTEKEntry OBJECT-TYPE SYNTAX DocsBpiCmTEKEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing the TEK association attributes of one SID. The CM MUST create one entry per unicast SID, regardless of whether the SID was obtained from a Registration Response message, or from an Authorization Reply message." INDEX { ifIndex, docsIfCmServiceId } ::= { docsBpiCmTEKTable 1 } DocsBpiCmTEKEntry ::= SEQUENCE { docsBpiCmTEKPrivacyEnable TruthValue, docsBpiCmTEKState INTEGER, docsBpiCmTEKExpiresOld DateAndTime, Expires August 2000 [Page 15] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 docsBpiCmTEKExpiresNew DateAndTime, docsBpiCmTEKKeyRequests Counter32, docsBpiCmTEKKeyReplies Counter32, docsBpiCmTEKKeyRejects Counter32, docsBpiCmTEKInvalids Counter32, docsBpiCmTEKAuthPends Counter32, docsBpiCmTEKKeyRejectErrorCode INTEGER, docsBpiCmTEKKeyRejectErrorString DisplayString, docsBpiCmTEKInvalidErrorCode INTEGER, docsBpiCmTEKInvalidErrorString DisplayString } docsBpiCmTEKPrivacyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies whether this SID is provisioned to run Baseline Privacy. This is analogous to enabling Baseline Privacy on a provisioned SID using the Class-of-Service Privacy Enable option. Baseline Privacy is not effectively enabled for any SID unless Baseline Privacy is enabled for the CM, which is managed via the docsBpiCmPrivacyEnable object." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.2." ::= { docsBpiCmTEKEntry 1 } docsBpiCmTEKState OBJECT-TYPE SYNTAX INTEGER { start(1), opWait(2), opReauthWait(3), operational(4), rekeyWait(5), rekeyReauthWait(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the state of the indicated TEK FSM. The start(1) state indicates that FSM is in its initial state." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.1.3.1." ::= { docsBpiCmTEKEntry 2 } docsBpiCmTEKExpiresOld OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only Expires August 2000 [Page 16] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 STATUS current DESCRIPTION "The value of this object is the actual clock time for expiration of the immediate predecessor of the most recent TEK for this FSM. If this FSM has only one TEK, then the value is the time of activation of this FSM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.5 and 4.2.2.9." ::= { docsBpiCmTEKEntry 3 } docsBpiCmTEKExpiresNew OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time for expiration of the most recent TEK for this FSM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.5 and 4.2.2.9." ::= { docsBpiCmTEKEntry 4 } docsBpiCmTEKKeyRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CM has transmitted a Key Request message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.4." ::= { docsBpiCmTEKEntry 5 } docsBpiCmTEKKeyReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CM has received a Key Reply message, including a message whose authentication failed." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.5." ::= { docsBpiCmTEKEntry 6 } docsBpiCmTEKKeyRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Expires August 2000 [Page 17] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 STATUS current DESCRIPTION "The value of this object is the count of times the CM has received a Key Reject message, including a message whose authentication failed." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.6." ::= { docsBpiCmTEKEntry 7 } docsBpiCmTEKInvalids OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CM has received a TEK Invalid message, including a message whose authentication failed." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.8." ::= { docsBpiCmTEKEntry 8 } docsBpiCmTEKAuthPends OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times an Authorization Pending (Auth Pend) event occurred in this FSM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.1.3.3.3." ::= { docsBpiCmTEKEntry 9 } docsBpiCmTEKKeyRejectErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), unauthorizedSid(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in most recent Key Reject message received by the CM. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no Key Reject message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.1.2.6 and 4.2.2.16." ::= { docsBpiCmTEKEntry 10 } Expires August 2000 [Page 18] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 docsBpiCmTEKKeyRejectErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Display-String in most recent Key Reject message received by the CM. This is a zero length string if no Key Reject message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.1.2.6 and 4.2.2.6." ::= { docsBpiCmTEKEntry 11 } docsBpiCmTEKInvalidErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), invalidKeySequence(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in most recent TEK Invalid message received by the CM. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no TEK Invalid message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.1.2.8 and 4.2.2.16." ::= { docsBpiCmTEKEntry 12 } docsBpiCmTEKInvalidErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Display-String in most recent TEK Invalid message received by the CM. This is a zero length string if no TEK Invalid message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.1.2.8 and 4.2.2.6." ::= { docsBpiCmTEKEntry 13 } -- Cable Modem Termination System Group docsBpiCmtsObjects OBJECT IDENTIFIER ::= { docsBpiMIBObjects 2 } Expires August 2000 [Page 19] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 -- -- The BPI base table for CMTSs, indexed by ifIndex -- docsBpiCmtsBaseTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpiCmtsBaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the basic Baseline Privacy attributes of each CMTS MAC interface." ::= { docsBpiCmtsObjects 1 } docsBpiCmtsBaseEntry OBJECT-TYPE SYNTAX DocsBpiCmtsBaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing attributes of one CMTS MAC interface. An entry in this table exists for each ifEntry with an ifType of docsCableMaclayer(127)." INDEX { ifIndex } ::= { docsBpiCmtsBaseTable 1 } DocsBpiCmtsBaseEntry ::= SEQUENCE { docsBpiCmtsDefaultAuthLifetime Integer32, docsBpiCmtsDefaultTEKLifetime Integer32, -- docsBpiCmtsDefaultAuthGraceTime Integer32, -- docsBpiCmtsDefaultTEKGraceTime Integer32, docsBpiCmtsAuthRequests Counter32, docsBpiCmtsAuthReplies Counter32, docsBpiCmtsAuthRejects Counter32, docsBpiCmtsAuthInvalids Counter32 } docsBpiCmtsDefaultAuthLifetime OBJECT-TYPE SYNTAX Integer32 (1..6048000) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object is the default lifetime, in seconds, the CMTS assigns to a new authorization key." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.2." ::= { docsBpiCmtsBaseEntry 1 } docsBpiCmtsDefaultTEKLifetime OBJECT-TYPE Expires August 2000 [Page 20] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 SYNTAX Integer32 (1..604800) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object is the default lifetime, in seconds, the CMTS assigns to a new Traffic Encryption Key (TEK)." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.2." ::= { docsBpiCmtsBaseEntry 2 } -- Note: the following two objects have been removed from this MIB. -- docsBpiCmtsDefaultAuthGraceTime OBJECT-TYPE -- SYNTAX Integer32 (1..1800) -- UNITS "seconds" -- MAX-ACCESS read-write -- STATUS current -- DESCRIPTION -- "Default grace time, in seconds, the CMTS uses for an authorization -- key. This controls how far in advance of authorization key expiration -- that the CMTS is expected to produce the next generation of keying -- material. This value is expected to agree with the Authorization Grace -- Time that the provisioning system provides to CMs." -- ::= { docsBpiCmtsBaseEntry 3 } -- docsBpiCmtsDefaultTEKGraceTime OBJECT-TYPE -- SYNTAX Integer32 (1..1800) -- UNITS "seconds" -- MAX-ACCESS read-write -- STATUS current -- DESCRIPTION -- "Default grace time, in seconds, the CMTS uses for a Traffic -- Encryption Key (TEK). This controls how far in advance of TEK -- expiration that the CMTS is expected to produce the next generation -- of keying material. This value is expected to agree with the TEK Grace -- Time that the provisioning system provides to CMs. Note that this -- object is particularly relevant for multicast SIDs, where multiple -- grace time values cannot be honored." -- ::= { docsBpiCmtsBaseEntry 4 } docsBpiCmtsAuthRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has received an Authorization Request message from any CM." Expires August 2000 [Page 21] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.1." ::= { docsBpiCmtsBaseEntry 5 } docsBpiCmtsAuthReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted an Authorization Reply message to any CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.2." ::= { docsBpiCmtsBaseEntry 6 } docsBpiCmtsAuthRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted an Authorization Reject message to any CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.3." ::= { docsBpiCmtsBaseEntry 7 } docsBpiCmtsAuthInvalids OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted an Authorization Invalid message to any CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.7." ::= { docsBpiCmtsBaseEntry 8 } -- -- The CMTS Authorization Table, indexed by ifIndex and CM MAC address -- docsBpiCmtsAuthTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpiCmtsAuthEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the attributes of each CM authorization association. The CMTS maintains one authorization association with Expires August 2000 [Page 22] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 each Baseline Privacy-enabled CM on each CMTS MAC interface." ::= { docsBpiCmtsObjects 2 } docsBpiCmtsAuthEntry OBJECT-TYPE SYNTAX DocsBpiCmtsAuthEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing attributes of one authorization association. The CMTS MUST create one entry per CM per MAC interface, based on the receipt of an Authorization Request message, and MUST not delete the entry before the CM authorization permanently expires." INDEX { ifIndex, docsBpiCmtsAuthCmMacAddress } ::= { docsBpiCmtsAuthTable 1 } DocsBpiCmtsAuthEntry ::= SEQUENCE { docsBpiCmtsAuthCmMacAddress MacAddress, docsBpiCmtsAuthCmPublicKey OCTET STRING, docsBpiCmtsAuthCmKeySequenceNumber Integer32, docsBpiCmtsAuthCmExpires DateAndTime, docsBpiCmtsAuthCmLifetime Integer32, docsBpiCmtsAuthCmGraceTime Integer32, docsBpiCmtsAuthCmReset INTEGER, docsBpiCmtsAuthCmRequests Counter32, docsBpiCmtsAuthCmReplies Counter32, docsBpiCmtsAuthCmRejects Counter32, docsBpiCmtsAuthCmInvalids Counter32, docsBpiCmtsAuthRejectErrorCode INTEGER, docsBpiCmtsAuthRejectErrorString DisplayString, docsBpiCmtsAuthInvalidErrorCode INTEGER, docsBpiCmtsAuthInvalidErrorString DisplayString } docsBpiCmtsAuthCmMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is the physical address of the CM to which the authorization association applies." ::= { docsBpiCmtsAuthEntry 1 } docsBpiCmtsAuthCmPublicKey OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 74 | 106 | 140 | 270)) MAX-ACCESS read-only STATUS current DESCRIPTION Expires August 2000 [Page 23] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 "The value of this object is a DER-encoded RSAPublicKey ASN.1 type string, as defined in the RSA Encryption Standard (PKCS #1) [22], corresponding to the public key of the CM. The 74, 106, 140, and 270 byte key encoding lengths correspond to 512 bit, 768 bit, 1024 bit, and 2048 public moduli respectively. This is a zero-length string if the CMTS does not retain the public key." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.2.4." ::= { docsBpiCmtsAuthEntry 2 } docsBpiCmtsAuthCmKeySequenceNumber OBJECT-TYPE SYNTAX Integer32 (0..15) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the authorization key sequence number for this CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.2 and 4.2.2.10." ::= { docsBpiCmtsAuthEntry 3 } docsBpiCmtsAuthCmExpires OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time when the current authorization for this CM expires. If this CM does not have an active authorization, then the value is of the expiration date and time of the last active authorization." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.2 and 4.2.2.9." ::= { docsBpiCmtsAuthEntry 4 } docsBpiCmtsAuthCmLifetime OBJECT-TYPE SYNTAX Integer32 (1..6048000) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object is the lifetime, in seconds, the CMTS assigns to an authorization key for this CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.2 and Appendix A.2." ::= { docsBpiCmtsAuthEntry 5 } Expires August 2000 [Page 24] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 docsBpiCmtsAuthCmGraceTime OBJECT-TYPE SYNTAX Integer32 (1..1800) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the grace time for the authorization key in seconds. The CM is expected to start trying to get a new authorization key beginning AuthGraceTime seconds before the authorization key actually expires." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.3." ::= { docsBpiCmtsAuthEntry 6 } docsBpiCmtsAuthCmReset OBJECT-TYPE SYNTAX INTEGER { noResetRequested(1), invalidateAuth(2), sendAuthInvalid(3), invalidateTeks(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to invalidateAuth(2) causes the CMTS to invalidate the current CM authorization key, but not to transmit an Authorization Invalid message nor to invalidate unicast TEKs. Setting this object to sendAuthInvalid(3) causes the CMTS to invalidate the current CM authorization key, and to transmit an Authorization Invalid message to the CM, but not to invalidate unicast TEKs. Setting this object to invalidateTeks(4) causes the CMTS to invalidate the current CM authorization key, to transmit an Authorization Invalid message to the CM, and to invalidate all unicast TEKs associated with this CM authorization. Reading this object returns the most-recently-set value of this object, or returns noResetRequested(1) if the object has not been set since the last CMTS reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.1.2.3.4, 4.1.2.3.5, and 4.1.3.3.5." ::= { docsBpiCmtsAuthEntry 7 } docsBpiCmtsAuthCmRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has received an Authorization Request message from this CM." Expires August 2000 [Page 25] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.1." ::= { docsBpiCmtsAuthEntry 8 } docsBpiCmtsAuthCmReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted an Authorization Reply message to this CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.2." ::= { docsBpiCmtsAuthEntry 9 } docsBpiCmtsAuthCmRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted an Authorization Reject message to this CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.3." ::= { docsBpiCmtsAuthEntry 10 } docsBpiCmtsAuthCmInvalids OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted an Authorization Invalid message to this CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.7." ::= { docsBpiCmtsAuthEntry 11 } docsBpiCmtsAuthRejectErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), unauthorizedCm(3), unauthorizedSid(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Expires August 2000 [Page 26] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 Error-Code in most recent Authorization Reject message transmitted to the CM. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no Authorization Reject message has been transmitted to the CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.3 and 4.2.2.16." ::= { docsBpiCmtsAuthEntry 12 } docsBpiCmtsAuthRejectErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Display-String in most recent Authorization Reject message transmitted to the CM. This is a zero length string if no Authorization Reject message has been transmitted to the CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.3 and 4.2.2.6." ::= { docsBpiCmtsAuthEntry 13 } docsBpiCmtsAuthInvalidErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), unauthorizedCm(3), unsolicited(5), invalidKeySequence(6), keyRequestAuthenticationFailure(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in most recent Authorization Invalid message transmitted to the CM. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no Authorization Invalid message has been transmitted to the CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.7 and 4.2.2.16." ::= { docsBpiCmtsAuthEntry 14 } docsBpiCmtsAuthInvalidErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only Expires August 2000 [Page 27] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 STATUS current DESCRIPTION "The value of this object is the Display-String in most recent Authorization Invalid message transmitted to the CM. This is a zero length string if no Authorization Invalid message has been transmitted to the CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.7 and 4.2.2.6." ::= { docsBpiCmtsAuthEntry 15 } -- -- The CMTS TEK Table, indexed by ifIndex and SID -- docsBpiCmtsTEKTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpiCmtsTEKEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the attributes of each CM Traffic Encryption Key (TEK) association. The CMTS maintains one TEK association per BPI SID on each CMTS MAC interface." ::= { docsBpiCmtsObjects 3 } docsBpiCmtsTEKEntry OBJECT-TYPE SYNTAX DocsBpiCmtsTEKEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing attributes of one TEK association on a particular CMTS MAC interface. The CMTS MUST create one entry per SID per MAC interface, based on the receipt of an Key Request message, and MUST not delete the entry before the CM authorization for the SID permanently expires." INDEX { ifIndex, docsIfCmtsServiceId } ::= { docsBpiCmtsTEKTable 1 } DocsBpiCmtsTEKEntry ::= SEQUENCE { docsBpiCmtsTEKLifetime Integer32, docsBpiCmtsTEKGraceTime Integer32, docsBpiCmtsTEKExpiresOld DateAndTime, docsBpiCmtsTEKExpiresNew DateAndTime, docsBpiCmtsTEKReset TruthValue, docsBpiCmtsKeyRequests Counter32, docsBpiCmtsKeyReplies Counter32, docsBpiCmtsKeyRejects Counter32, docsBpiCmtsTEKInvalids Counter32, Expires August 2000 [Page 28] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 docsBpiCmtsKeyRejectErrorCode INTEGER, docsBpiCmtsKeyRejectErrorString DisplayString, docsBpiCmtsTEKInvalidErrorCode INTEGER, docsBpiCmtsTEKInvalidErrorString DisplayString } docsBpiCmtsTEKLifetime OBJECT-TYPE SYNTAX Integer32 (1..604800) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object is the lifetime, in seconds, the CMTS assigns to keys for this TEK association." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.5 and Appendix A.2." ::= { docsBpiCmtsTEKEntry 1 } docsBpiCmtsTEKGraceTime OBJECT-TYPE SYNTAX Integer32 (1..1800) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the grace time for the TEK in seconds. The CM is expected to start trying to get a new TEK beginning TEKGraceTime seconds before the TEK actually expires." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.6." ::= { docsBpiCmtsTEKEntry 2 } docsBpiCmtsTEKExpiresOld OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time for expiration of the immediate predecessor of the most recent TEK for this FSM. If this FSM has only one TEK, then the value is the time of activation of this FSM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.5 and 4.2.2.9." ::= { docsBpiCmtsTEKEntry 3 } docsBpiCmtsTEKExpiresNew OBJECT-TYPE SYNTAX DateAndTime Expires August 2000 [Page 29] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time for expiration of the most recent TEK for this FSM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.5 and 4.2.2.9." ::= { docsBpiCmtsTEKEntry 4 } docsBpiCmtsTEKReset OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to TRUE causes the CMTS to invalidate the current active TEK(s) (plural due to key transition periods), and to generate a new TEK for the associated SID; the CMTS MAY also generate an unsolicited TEK Invalid message, to optimize the TEK synchronization between the CMTS and the CM. Reading this object always returns FALSE." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.1.3.3.5." ::= { docsBpiCmtsTEKEntry 5 } docsBpiCmtsKeyRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has received a Key Request message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.4." ::= { docsBpiCmtsTEKEntry 6 } docsBpiCmtsKeyReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted a Key Reply message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.5." ::= { docsBpiCmtsTEKEntry 7 } docsBpiCmtsKeyRejects OBJECT-TYPE SYNTAX Counter32 Expires August 2000 [Page 30] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted a Key Reject message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.6." ::= { docsBpiCmtsTEKEntry 8 } docsBpiCmtsTEKInvalids OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted a TEK Invalid message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.8." ::= { docsBpiCmtsTEKEntry 9 } docsBpiCmtsKeyRejectErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), unauthorizedSid(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in the most recent Key Reject message sent in response to a Key Request for this BPI SID. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no Key Reject message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.6 and 4.2.2.16." ::= { docsBpiCmtsTEKEntry 10 } docsBpiCmtsKeyRejectErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Display-String in the most recent Key Reject message sent in response to a Key Request for this BPI SID. This is a zero length string if no Key Reject message has been received since reboot." Expires August 2000 [Page 31] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.6 and 4.2.2.6." ::= { docsBpiCmtsTEKEntry 11 } docsBpiCmtsTEKInvalidErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), invalidKeySequence(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in the most recent TEK Invalid message sent in association with this BPI SID. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no TEK Invalid message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.8 and 4.2.2.16." ::= { docsBpiCmtsTEKEntry 12 } docsBpiCmtsTEKInvalidErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Display-String in the most recent TEK Invalid message sent in association with this BPI SID. This is a zero length string if no TEK Invalid message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.8 and 4.2.2.6." ::= { docsBpiCmtsTEKEntry 13 } -- -- The CMTS Multicast Control Group -- docsBpiMulticastControl OBJECT IDENTIFIER ::= { docsBpiCmtsObjects 4 } -- -- The CMTS IP Multicast Mapping Table, indexed by IP multicast -- address and prefix, and by ifindex -- Expires August 2000 [Page 32] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 docsBpiIpMulticastMapTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpiIpMulticastMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the mapping of IP multicast address prefixes to multicast SIDs on each CMTS MAC interface." ::= { docsBpiMulticastControl 1 } docsBpiIpMulticastMapEntry OBJECT-TYPE SYNTAX DocsBpiIpMulticastMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing the mapping of one IP multicast address prefix to one multicast SID on one CMTS MAC interface. The CMTS uses the mapping when forwarding downstream IP multicast traffic." INDEX { ifIndex, docsBpiIpMulticastAddress, docsBpiIpMulticastPrefixLength } ::= { docsBpiIpMulticastMapTable 1 } DocsBpiIpMulticastMapEntry ::= SEQUENCE { docsBpiIpMulticastAddress IpAddress, docsBpiIpMulticastPrefixLength Integer32, docsBpiIpMulticastServiceId Integer32, docsBpiIpMulticastMapControl RowStatus } docsBpiIpMulticastAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the IP multicast address (prefix) to be mapped by this row, in conjunction with docsBpiIpMulticastPrefixLength." ::= { docsBpiIpMulticastMapEntry 1 } docsBpiIpMulticastPrefixLength OBJECT-TYPE SYNTAX Integer32 (0..32) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the IP multicast address prefix length for this row. The value of this object represents the length in bits of docsBpiIpMulticastAddress for multicast address comparisons, using big-endian ordering. An IP multicast address Expires August 2000 [Page 33] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 matches this row if the (docsBpiIpMulticastPrefixLength) most significant bits of the IP multicast address and of the (docsBpiIpMulticastAddress) are identical. This object is similar in usage to an IP address mask. The value 0 corresponds to IP address mask 0.0.0.0, the value 1 corresponds to IP address mask 128.0.0.0, the value 8 corresponds to IP address mask 255.0.0.0, and the value 32 corresponds to IP address mask 255.255.255.255." ::= { docsBpiIpMulticastMapEntry 2 } docsBpiIpMulticastServiceId OBJECT-TYPE SYNTAX Integer32 (8192..16368) MAX-ACCESS read-create STATUS current DESCRIPTION "This object represents the multicast SID to be used in this IP multicast address prefix mapping entry." -- DEFVAL is an unused multicast SID value chosen by CMTS. ::= { docsBpiIpMulticastMapEntry 3 } docsBpiIpMulticastMapControl OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls and reflects the IP multicast address prefix mapping entry." ::= { docsBpiIpMulticastMapEntry 4 } -- -- The CMTS Multicast SID Authorization Table, indexed by ifIndex by -- multicast SID by CM MAC address -- docsBpiMulticastAuthTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpiMulticastAuthEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the multicast SID authorization for each CM on each CMTS MAC interface." ::= { docsBpiMulticastControl 2 } docsBpiMulticastAuthEntry OBJECT-TYPE SYNTAX DocsBpiMulticastAuthEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires August 2000 [Page 34] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 "Each entry contains objects describing the key authorization of one cable modem for one multicast SID for one CMTS MAC interface." INDEX { ifIndex, docsBpiMulticastServiceId, docsBpiMulticastCmMacAddress } ::= { docsBpiMulticastAuthTable 1 } DocsBpiMulticastAuthEntry ::= SEQUENCE { docsBpiMulticastServiceId Integer32, docsBpiMulticastCmMacAddress MacAddress, docsBpiMulticastAuthControl RowStatus } docsBpiMulticastServiceId OBJECT-TYPE SYNTAX Integer32 (8192..16368) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the multicast SID for authorization." ::= { docsBpiMulticastAuthEntry 1 } docsBpiMulticastCmMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the MAC address of the CM to which the multicast SID authorization applies." ::= { docsBpiMulticastAuthEntry 2 } docsBpiMulticastAuthControl OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls and reflects the CM authorization for each multicast SID." ::= { docsBpiMulticastAuthEntry 3 } -- -- The BPI MIB Conformance Statements (with a placeholder for -- notifications) -- docsBpiNotification OBJECT IDENTIFIER ::= { docsBpiMIB 2 } docsBpiConformance OBJECT IDENTIFIER ::= { docsBpiMIB 3 } docsBpiCompliances OBJECT IDENTIFIER ::= { docsBpiConformance 1 } docsBpiGroups OBJECT IDENTIFIER ::= { docsBpiConformance 2 } Expires August 2000 [Page 35] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 docsBpiBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "This is the compliance statement for devices which implement the DOCSIS Baseline Privacy Interface." MODULE -- docsBpiMIB -- conditionally mandatory group GROUP docsBpiCmGroup DESCRIPTION "This group is implemented only in CMs, not in CMTSs." -- conditionally mandatory group GROUP docsBpiCmtsGroup DESCRIPTION "This group is implemented only in CMTSs, not in CMs." -- relaxation on mandatory range (unnecessary since object is read-only) -- OBJECT docsBpiCmAuthGraceTime -- SYNTAX Integer32 (300..1800) -- DESCRIPTION -- "The refined range corresponds to the minimum and maximum values in -- operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range (unnecessary since object is read-only) -- OBJECT docsBpiCmTEKGraceTime -- SYNTAX Integer32 (300..1800) -- DESCRIPTION -- "The refined range corresponds to the minimum and maximum values in -- operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range OBJECT docsBpiCmtsDefaultAuthLifetime SYNTAX Integer32 (86400..6048000) DESCRIPTION "The refined range corresponds to the minimum and maximum values in operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range OBJECT docsBpiCmtsDefaultTEKLifetime SYNTAX Integer32 (1800..604800) DESCRIPTION "The refined range corresponds to the minimum and maximum values in operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range (object removed from MIB) -- OBJECT docsBpiCmtsDefaultAuthGraceTime Expires August 2000 [Page 36] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 -- SYNTAX INTEGER (300..1800) -- DESCRIPTION -- "The refined range corresponds to the minimum and maximum values in -- operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range (object removed from MIB) -- OBJECT docsBpiCmtsDefaultTEKGraceTime -- SYNTAX INTEGER (300..1800) -- DESCRIPTION -- "The refined range corresponds to the minimum and maximum values in -- operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range OBJECT docsBpiCmtsAuthCmLifetime SYNTAX Integer32 (86400..6048000) DESCRIPTION "The refined range corresponds to the minimum and maximum values in operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range (unnecessary since object is read-only) -- OBJECT docsBpiCmtsAuthCmGraceTime -- SYNTAX Integer32 (300..1800) -- DESCRIPTION -- "The refined range corresponds to the minimum and maximum values in -- operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range OBJECT docsBpiCmtsTEKLifetime SYNTAX Integer32 (1800..604800) DESCRIPTION "The refined range corresponds to the minimum and maximum values in operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range (unnecessary since object is read-only) -- OBJECT docsBpiCmtsTEKGraceTime -- SYNTAX Integer32 (300..1800) -- DESCRIPTION -- "The refined range corresponds to the minimum and maximum values in -- operational networks, according to Appendix A.2 in [18]." ::= { docsBpiCompliances 1 } docsBpiCmGroup OBJECT-GROUP OBJECTS { docsBpiCmPrivacyEnable, docsBpiCmPublicKey, docsBpiCmAuthState, docsBpiCmAuthKeySequenceNumber, Expires August 2000 [Page 37] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 docsBpiCmAuthExpires, docsBpiCmAuthReset, docsBpiCmAuthGraceTime, docsBpiCmTEKGraceTime, docsBpiCmAuthWaitTimeout, docsBpiCmReauthWaitTimeout, docsBpiCmOpWaitTimeout, docsBpiCmRekeyWaitTimeout, docsBpiCmAuthRejectWaitTimeout, docsBpiCmAuthRequests, docsBpiCmAuthReplies, docsBpiCmAuthRejects, docsBpiCmAuthInvalids, docsBpiCmAuthRejectErrorCode, docsBpiCmAuthRejectErrorString, docsBpiCmAuthInvalidErrorCode, docsBpiCmAuthInvalidErrorString, docsBpiCmTEKPrivacyEnable, docsBpiCmTEKState, docsBpiCmTEKExpiresOld, docsBpiCmTEKExpiresNew, docsBpiCmTEKKeyRequests, docsBpiCmTEKKeyReplies, docsBpiCmTEKKeyRejects, docsBpiCmTEKInvalids, docsBpiCmTEKAuthPends, docsBpiCmTEKKeyRejectErrorCode, docsBpiCmTEKKeyRejectErrorString, docsBpiCmTEKInvalidErrorCode, docsBpiCmTEKInvalidErrorString } STATUS current DESCRIPTION "This collection of objects provides CM BPI status and control." ::= { docsBpiGroups 1 } docsBpiCmtsGroup OBJECT-GROUP OBJECTS { docsBpiCmtsDefaultAuthLifetime, docsBpiCmtsDefaultTEKLifetime, -- docsBpiCmtsDefaultAuthGraceTime, -- docsBpiCmtsDefaultTEKGraceTime, docsBpiCmtsAuthRequests, docsBpiCmtsAuthReplies, docsBpiCmtsAuthRejects, docsBpiCmtsAuthInvalids, docsBpiCmtsAuthCmPublicKey, docsBpiCmtsAuthCmKeySequenceNumber, Expires August 2000 [Page 38] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 docsBpiCmtsAuthCmExpires, docsBpiCmtsAuthCmLifetime, docsBpiCmtsAuthCmGraceTime, docsBpiCmtsAuthCmReset, docsBpiCmtsAuthCmRequests, docsBpiCmtsAuthCmReplies, docsBpiCmtsAuthCmRejects, docsBpiCmtsAuthCmInvalids, docsBpiCmtsAuthRejectErrorCode, docsBpiCmtsAuthRejectErrorString, docsBpiCmtsAuthInvalidErrorCode, docsBpiCmtsAuthInvalidErrorString, docsBpiCmtsTEKLifetime, docsBpiCmtsTEKGraceTime, docsBpiCmtsTEKExpiresOld, docsBpiCmtsTEKExpiresNew, docsBpiCmtsTEKReset, docsBpiCmtsKeyRequests, docsBpiCmtsKeyReplies, docsBpiCmtsKeyRejects, docsBpiCmtsTEKInvalids, docsBpiCmtsKeyRejectErrorCode, docsBpiCmtsKeyRejectErrorString, docsBpiCmtsTEKInvalidErrorCode, docsBpiCmtsTEKInvalidErrorString, docsBpiIpMulticastServiceId, docsBpiIpMulticastMapControl, docsBpiMulticastAuthControl } STATUS current DESCRIPTION "This collection of objects provides CMTS BPI status and control." ::= { docsBpiGroups 2 } END 5. Acknowledgments This document was produced by the IPCDN Working Group. Much of the content of this MIB was conceived by Chet Birger and Mike StJohns. Kazuyoshi Ozawa and Bob Himlin provided many useful technical corrections. 6. References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. Expires August 2000 [Page 39] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information for Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [14] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol Expires August 2000 [Page 40] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 (SNMP)", RFC 2575, April 1999. [16] St. Johns, M., editor, "Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces", RFC 2670, August 1999. [17] St. Johns, M., editor, "DOCSIS Cable Device MIB, Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems", RFC 2669, August 1999. [18] "Data-Over-Cable Service Interface Specifications: Baseline Privacy Interface Specification SP-BPI-I02-990319", DOCSIS, March 1999, http://www.cablemodem.com/. [19] "Data-Over-Cable Service Interface Specifications: Cable Modem Radio Frequency Interface Specification SP-RFI-I05-991105", DOCSIS, November 1999, http://www.cablemodem.com/. [20] "Data-Over-Cable Service Interface Specifications: Operations Support System Interface Specification RF Interface SP-OSSI-RF- I02-980410", DOCSIS, April 1998, http://www.cablemodem.com/. [21] "Data-Over-Cable Service Interface Specifications: Baseline Privacy Plus Interface Specification SP-BPI+-I03-991105", DOCSIS, November 1999, http://www.cablemodem.com/. [22] RSA Laboratories, "The Public-Key Cryptography Standards", RSA Data Security Inc., Redwood City, CA. [23] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7. Security Considerations The Baseline Privacy Interface provides data encryption for DOCSIS data-over-cable services. Baseline Privacy-capable cable modems have RSA private/public key pairs installed by manufacturers. The public key is used to encrypt an Authorization key, and the Authorization key is used to encrypt one or more Traffic Encryption Keys (TEKs). The TEKs are used to encrypt both upstream and downstream data traffic. Please refer to [18] to obtain further information on the Baseline Privacy specification. In particular, the Baseline Privacy Interface does not provide an authentication service. CMTS implementors are encouraged not to rely on the MAC address of the CM for service authorization -- in particular, for the docsBpiMulticastAuthTable in this MIB. The Baseline Privacy Plus Interface does provide a CM authentication Expires August 2000 [Page 41] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 service, and the working group expects to issue a MIB for the management of BPI+ at a later time. This MIB specification contains a number of read-write objects, that should be protected from unauthorized modification to prevent denial of service and theft of service attacks: in particular, objects that reset state machines (ex. docsBpiCmAuthReset), change key lifetimes (ex. docsBpiCmtsDefaultAuthLifetime), change rekeying grace times (ex. docsBpiCmtsDefaultAuthGraceTime), and control multicast traffic (ex. most objects in the docsBpiMulticastControl group). The desired means to protect these objects from unwarranted access is to implement the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model [12] and the View-based Access Control Model [15] is recommended. Weaker methods to protect CMs from unauthorized access include using the docsDevNmAccessTable from the Cable Device MIB [17] to disallow configuration changes from unauthorized network management stations, and using the SNMP MIB Object and SNMP Write-Access Control configuration file options from the Radio Frequency Interface [19] to set MIB object values and disable SNMP SET operations at cable modem boot time. Note that these mechanisms may be vulnerable to an unauthorized network management station "spoofing" the source address of a legitimate network management station. 8. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Expires August 2000 [Page 42] INTERNET-DRAFT DOCSIS Baseline Privacy MIB February 2000 9. Author's Address Richard Woundy Cisco Systems 250 Apollo Drive Chelmsford, MA 01824 U.S.A. Phone: +1 978 244 8000 Email: rwoundy@cisco.com 10. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Expires August 2000 [Page 43] --=====================_35249115==_ Content-Type: text/plain; charset="us-ascii" --=====================_35249115==_-- From owner-ipcdn@terayon.com Thu Feb 17 12:13:48 2000 Received: from www.terayon.com (terayon.com [157.22.250.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18992 for ; Thu, 17 Feb 2000 12:13:42 -0500 (EST) Received: from redpine.terayon.com (redpine [157.22.250.5]) by www.terayon.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id JAA22590 for ; Thu, 17 Feb 2000 09:13:36 -0800 (PST) Received: from mail-serv.terayon.com by redpine.terayon.com via smtpd (for mails.terayon.com [157.22.250.1]) with SMTP; 17 Feb 2000 17:13:36 UT Received: from tamarind.terayon.com (tamarind.terayon.com [172.20.0.6]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id JAA29893; Thu, 17 Feb 2000 09:13:28 -0800 (PST) Received: (from root@localhost) by tamarind.terayon.com (8.8.8+Sun/8.8.8) id JAA27666 for ipcdn-outgoing; Thu, 17 Feb 2000 09:12:11 -0800 (PST) Message-ID: <4DF5E8A771ECD21187020008C7B1C5AF984363@srvmail.cablelabs.com> From: Kazuyoshi Ozawa To: "Ipcdn (E-mail)" , DOCSIS OSS Majordomo List Subject: New BPI+ MIB is available on the IETF Web Date: Thu, 17 Feb 2000 10:12:24 -0700 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-ipcdn@terayon.com Precedence: bulk Reply-To: ipcdn@terayon.com All, Thanks to Stuart Green from Arris Interactive, the new Internet Draft of BPI+ MIB is available on the IETF web. Please visit the page for the list of Internet Drafts for IPCDN WG at http://www.ietf.org/ids.by.wg/ipcdn.html Or directly get the BPI+ MIB at http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-bpiplus-mib-01.txt DOCSIS is going to issue the 1st OSSI Interim Spec at the end of March and we have to decide if this version is good engouth as the BPI+ MIB for the DOCSIS 1.1 in a couple of weeks. Let's review and discuss!!! Thanks, kaz Kaz Ozawa Toshiba Visiting Engineer at CableLabs Tel: 303-661-3860 (direct); 9199 (fax); 9100 (main) Email: k.ozawa@cablelabs.com / kaz@pobox.com From owner-ipcdn@terayon.com Tue Feb 22 22:51:03 2000 Received: from www.terayon.com (terayon.com [157.22.250.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01844 for ; Tue, 22 Feb 2000 22:51:02 -0500 (EST) Received: from redpine.terayon.com (redpine [157.22.250.5]) by www.terayon.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id TAA14832 for ; Tue, 22 Feb 2000 19:51:01 -0800 (PST) Received: from mail-serv.terayon.com by redpine.terayon.com via smtpd (for mails.terayon.com [157.22.250.1]) with SMTP; 23 Feb 2000 03:51:01 UT Received: from tamarind.terayon.com (tamarind.terayon.com [172.20.0.6]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id TAA20073; Tue, 22 Feb 2000 19:50:46 -0800 (PST) Received: (from root@localhost) by tamarind.terayon.com (8.8.8+Sun/8.8.8) id TAA04917 for ipcdn-outgoing; Tue, 22 Feb 2000 19:48:24 -0800 (PST) Message-ID: <4DF5E8A771ECD21187020008C7B1C5AF98437E@srvmail.cablelabs.com> From: Kazuyoshi Ozawa To: DOCSIS OSS Majordomo List , "Ipcdn (E-mail)" Subject: New BPI MIB (bpi-mib-01) is now available on the IETF Web Date: Tue, 22 Feb 2000 20:48:09 -0700 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-ipcdn@terayon.com Precedence: bulk Reply-To: ipcdn@terayon.com All, Thanks to Rich Woundy from Cisco Systems, the new Internet Draft of BPI MIB is now available on the IETF web, too!!!! Please visit the page for the list of Internet Drafts for IPCDN WG at http://www.ietf.org/ids.by.wg/ipcdn.html Or directly get the BPI+ MIB at http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-mcns-bpi-mib-01.txt I believe that this version will be the best one to resolve the technical issues the bpi-mib-00 with the minimum impact. Therefore, I am planning to propose an ECR to change the DOCSIS BPI MIB requirement from bpi-mib-00 to this. If the ECR is accepted as an ECN, it will become effective for the DOCSIS certification which starts two month or more after the acceptance. I also planning to require the 1.1 CM to support this BPI MIB when it is connected to the 1.0 CMTS and is operating in BPI mode. Thanks, kaz Kaz Ozawa Toshiba Visiting Engineer at CableLabs Tel: 303-661-3860 (direct); 9199 (fax); 9100 (main) Email: k.ozawa@cablelabs.com / kaz@pobox.com From owner-ipcdn@terayon.com Wed Feb 23 21:03:26 2000 Received: from www.terayon.com (terayon.com [157.22.250.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06784 for ; Wed, 23 Feb 2000 21:03:25 -0500 (EST) Received: from redpine.terayon.com (redpine [157.22.250.5]) by www.terayon.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id SAA27826 for ; Wed, 23 Feb 2000 18:00:56 -0800 (PST) Received: from mail-serv.terayon.com by redpine.terayon.com via smtpd (for mails.terayon.com [157.22.250.1]) with SMTP; 24 Feb 2000 02:00:55 UT Received: from tamarind.terayon.com (tamarind.terayon.com [172.20.0.6]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id SAA03034; Wed, 23 Feb 2000 18:00:49 -0800 (PST) Received: (from root@localhost) by tamarind.terayon.com (8.8.8+Sun/8.8.8) id RAA17460 for ipcdn-outgoing; Wed, 23 Feb 2000 17:58:55 -0800 (PST) Message-Id: <4.2.2.20000223175549.00cb3990@poptart> X-Sender: stjohns@poptart X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 23 Feb 2000 17:59:01 -0800 To: ipcdn@terayon.com From: "Mike St. Johns" Subject: Meeting Schedule. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipcdn@terayon.com Precedence: bulk Reply-To: ipcdn@terayon.com According to the meeting agenda, the IPCDN meeting is schedule for 1530 on Monday 27 March. This is a two hour session. I have agenda items from Rich Woundy and no one else so far. If you expect time, please send my your items ASAP. I'll be posting a preliminary agenda by Friday. Mike From owner-ipcdn@terayon.com Thu Feb 24 11:17:25 2000 Received: from www.terayon.com (terayon.com [157.22.250.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04539 for ; Thu, 24 Feb 2000 11:17:24 -0500 (EST) Received: from redpine.terayon.com (redpine [157.22.250.5]) by www.terayon.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id IAA03769; Thu, 24 Feb 2000 08:13:22 -0800 (PST) Received: from mail-serv.terayon.com by redpine.terayon.com via smtpd (for mails.terayon.com [157.22.250.1]) with SMTP; 24 Feb 2000 16:13:21 UT Received: from tamarind.terayon.com (tamarind.terayon.com [172.20.0.6]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id IAA18838; Thu, 24 Feb 2000 08:13:20 -0800 (PST) Received: (from root@localhost) by tamarind.terayon.com (8.8.8+Sun/8.8.8) id IAA22515 for ipcdn-outgoing; Thu, 24 Feb 2000 08:09:38 -0800 (PST) Message-Id: <200002241609.LAA28836@dragonfly.corp.home.net> X-Mailer: exmh version 2.1.0 09/18/1999 To: ipcdn@terayon.com Subject: Re: Meeting Schedule. In-Reply-To: Your message of "Wed, 23 Feb 2000 17:59:01 PST." <4.2.2.20000223175549.00cb3990@poptart> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Feb 2000 11:09:53 -0500 From: Ran Atkinson Sender: owner-ipcdn@terayon.com Precedence: bulk Reply-To: ipcdn@terayon.com I would like to see the EuroModem work be on the agenda. Perhaps we could develop a workplan and milestones for the EuroModem MIBs at the meeting (that could then be run past IESG for formal approval as a charter addition) ? Is someone from the EuroModem community going to be present that could give a status update ? If so, that would also be helpful. Ran rja@corp.home.net From owner-ipcdn@terayon.com Thu Feb 24 12:46:37 2000 Received: from www.terayon.com (terayon.com [157.22.250.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07126 for ; Thu, 24 Feb 2000 12:46:35 -0500 (EST) Received: from redpine.terayon.com (redpine [157.22.250.5]) by www.terayon.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id JAA05687; Thu, 24 Feb 2000 09:44:06 -0800 (PST) Received: from mail-serv.terayon.com by redpine.terayon.com via smtpd (for mails.terayon.com [157.22.250.1]) with SMTP; 24 Feb 2000 17:44:06 UT Received: from tamarind.terayon.com (tamarind.terayon.com [172.20.0.6]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id JAA23509; Thu, 24 Feb 2000 09:44:05 -0800 (PST) Received: (from root@localhost) by tamarind.terayon.com (8.8.8+Sun/8.8.8) id JAA24180 for ipcdn-outgoing; Thu, 24 Feb 2000 09:42:14 -0800 (PST) Message-Id: <4.2.2.20000224093451.00c49d10@poptart> X-Sender: stjohns@poptart X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 24 Feb 2000 09:35:05 -0800 To: ipcdn@terayon.com, ipcdn@terayon.com From: "Mike St. Johns" Subject: Re: Meeting Schedule. In-Reply-To: <200002241609.LAA28836@dragonfly.corp.home.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipcdn@terayon.com Precedence: bulk Reply-To: ipcdn@terayon.com Its on the schedule - its a Rich item. Mike At 08:09 AM 2/24/00 , Ran Atkinson wrote: >I would like to see the EuroModem work be on the agenda. > >Perhaps we could develop a workplan and milestones for the EuroModem MIBs >at the meeting (that could then be run past IESG for formal approval as a >charter addition) ? > >Is someone from the EuroModem community going to be present >that could give a status update ? If so, that would also >be helpful. > >Ran >rja@corp.home.net From owner-ipcdn@terayon.com Thu Feb 24 14:40:11 2000 Received: from www.terayon.com (terayon.com [157.22.250.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09138 for ; Thu, 24 Feb 2000 14:40:10 -0500 (EST) Received: from redpine.terayon.com (redpine [157.22.250.5]) by www.terayon.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id LAA07586; Thu, 24 Feb 2000 11:38:53 -0800 (PST) Received: from mail-serv.terayon.com by redpine.terayon.com via smtpd (for mails.terayon.com [157.22.250.1]) with SMTP; 24 Feb 2000 19:38:53 UT Received: from tamarind.terayon.com (tamarind.terayon.com [172.20.0.6]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id LAA28852; Thu, 24 Feb 2000 11:38:52 -0800 (PST) Received: (from root@localhost) by tamarind.terayon.com (8.8.8+Sun/8.8.8) id LAA25959 for ipcdn-outgoing; Thu, 24 Feb 2000 11:35:03 -0800 (PST) Message-Id: <200002241935.OAA01701@funnel.cisco.com> X-Sender: rwoundy@funnel X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 24 Feb 2000 14:38:53 -0500 To: ipcdn@terayon.com From: Rich Woundy Subject: Re: Meeting Schedule. Cc: a_valentine@hnsltd.hns.com In-Reply-To: <4.2.2.20000224093451.00c49d10@poptart> References: <200002241609.LAA28836@dragonfly.corp.home.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipcdn@terayon.com Precedence: bulk Reply-To: ipcdn@terayon.com I can certainly talk about the DOCSIS/Euromodem MIB comparison work that I did with Andrew Valentine (Hughes Network Systems). Hopefully, Andrew will also attend, and provide further Euromodem status. I think he wanted to finish one or more Euromodem MIB Internet draft(s) before Adelaide. Andrew, can you confirm??? -- Rich At 09:35 AM 2/24/00 -0800, Mike St. Johns wrote: >Its on the schedule - its a Rich item. > >Mike > > >At 08:09 AM 2/24/00 , Ran Atkinson wrote: > >>I would like to see the EuroModem work be on the agenda. >> >>Perhaps we could develop a workplan and milestones for the EuroModem MIBs >>at the meeting (that could then be run past IESG for formal approval as a >>charter addition) ? >> >>Is someone from the EuroModem community going to be present >>that could give a status update ? If so, that would also >>be helpful. >> >>Ran >>rja@corp.home.net > From owner-ipcdn@terayon.com Mon Feb 28 09:04:28 2000 Received: from www.terayon.com (terayon.com [157.22.250.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08796 for ; Mon, 28 Feb 2000 09:04:27 -0500 (EST) Received: from redpine.terayon.com (redpine [157.22.250.5]) by www.terayon.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id GAA06868 for ; Mon, 28 Feb 2000 06:04:11 -0800 (PST) Received: from mail-serv.terayon.com by redpine.terayon.com via smtpd (for mails.terayon.com [157.22.250.1]) with SMTP; 28 Feb 2000 14:04:10 UT Received: from tamarind.terayon.com (tamarind.terayon.com [172.20.0.6]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id GAA00173; Mon, 28 Feb 2000 06:03:55 -0800 (PST) Received: (from root@localhost) by tamarind.terayon.com (8.8.8+Sun/8.8.8) id GAA21364 for ipcdn-outgoing; Mon, 28 Feb 2000 06:00:42 -0800 (PST) Message-Id: <4.1.20000228084058.0098ff00@cliffie.ne.arris-i.com> X-Sender: wsawyer@cliffie.ne.arris-i.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 28 Feb 2000 08:53:00 -0500 To: Minnie Lu , stjohns@corp.home.net From: Wilson Sawyer Subject: Re: comments/questions for Subscriber Management MIB Cc: ipcdn@terayon.com, milu@cisco.com, apalmer@cisco.com, "Siripunkaw, Pak" In-Reply-To: <200002240425.UAA12711@paleale.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipcdn@terayon.com Precedence: bulk Reply-To: ipcdn@terayon.com Minnie - thanks for the comments. Replies interspersed. At 08:25 PM 2/23/00 -0800, Minnie Lu wrote: >Hi, > > I have some comments/questions for Subscriber Management MIB >(draft-ietf-ipcdn-subscriber-mib-00.txt) and appreciate any help in advance >! If any of them are discussed before, sorry to repeat them and would >appreciate letting me know the result. > > 1. In MIB module description, it says :"This will be rooted in >experimental space with future transition to be incorporated into the cable >device MIB." This MIB is in the MUST list of DOCSIS1.1 OSSI draft spec for >CMTS. When will it happen and have a real root ? I don't have a good answer for you. Mike? > 2. docsSubMgtCpeControlMaxCpeIp has the range (0..16). To me, this >implies that the max CPE IP in the provisioning object is 16. But, CPE IP >can be "learned", so > a) if the docsSubMgtCpeControlActive is true, the number of entries in >docsSubMgtCpeIpTable could NOT be more than docsSubMgtCpeControlMaxCpeIp >which max is16. Right ? > b) if the docsSubMgtCpeControlActive is false, the number of entries in >docsSubMgtCpeIpTable could be more than 16. Right ? > c) Since docsSubMgtCpeControlActive is RW, if a user set it to false from >true, and at that moment, there are more than 16 entries in >docsSubMgtCpeIpTable already, does it mean no more learned CPE IP ? But the >existing CPE IP are still kept in the table, right ? I would answer that (a), (b), and (c) are correct as you've stated. In the next draft, the limit of '16' will be removed from the mib. Your interpretation of (d) is reasonable, but maybe getting into implementation detail. Do you think we need to state this in the MIB? > > 3. comment: docsSubMgtCpeControlLearnable: > a) "If this is set to true, up to MaxCpeIp Address are learned related to >this CM." Would it be better to say "If this is set to true, up to number >of docsSubMgtCpeControlMaxCpeIp Address can be learned related to this CM." ? Your wording is probably clearer, but is there a substantive point that I'm missing? > b) Also please add explanation of "learned" (what does it mean 'learned' >?) since in the MIB definition, this is the first time the word 'learn' is >mentioned. > c) What if this is set to false ? Please explain more for false condition. Acknowledged. will address in next draft. We don't want to go too far, though, in defining 'learned', since we want to leave open a variety of learning mechanisms at the CMTS. > 4. docsSubMgtPktFilterIndex: in the description of >docsSubMgtPktFilterTable, it says that "no more than 20 classifiers", does >it mean the FilterIndex is 1 .. 20 ? Need a range for it ? will be fixed in next draft. The limit has been removed per Guenter's suggestion. > 5. docsSubMgtCmFilterDownstream (same for docsSubMgtCmFilterUpstream) could >be set to the default which could be 0 upon the initial CMTS initialization. > a) What does it mean for the value 0 here ? > b) Also it is RW, could a user set the value to 0 on purposely ? >(Same questions for docsSubMgtCmFilterDownDefault and >docsSubMgtCmFilterUpDefault). I'll look at this. > Thanks a lot for your help again in advance ! > Minnie > > Wilson Sawyer wsawyer@ieee.org Arris Interactive (978) 946 4711 6 Riverside Drive fax (978) 946 4900 Andover, MA 01810 From owner-ipcdn@terayon.com Mon Feb 28 17:18:45 2000 Received: from www.terayon.com (terayon.com [157.22.250.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22071 for ; Mon, 28 Feb 2000 17:18:36 -0500 (EST) Received: from redpine.terayon.com (redpine [157.22.250.5]) by www.terayon.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id OAA14081; Mon, 28 Feb 2000 14:14:58 -0800 (PST) Received: from mail-serv.terayon.com by redpine.terayon.com via smtpd (for mails.terayon.com [157.22.250.1]) with SMTP; 28 Feb 2000 22:14:58 UT Received: from tamarind.terayon.com (tamarind.terayon.com [172.20.0.6]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id OAA23134; Mon, 28 Feb 2000 14:14:57 -0800 (PST) Received: (from root@localhost) by tamarind.terayon.com (8.8.8+Sun/8.8.8) id OAA29663 for ipcdn-outgoing; Mon, 28 Feb 2000 14:12:28 -0800 (PST) Message-Id: <4.2.2.20000228135600.05ed3870@poptart> X-Sender: stjohns@poptart X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 28 Feb 2000 14:10:52 -0800 To: Wilson Sawyer , Minnie Lu , stjohns@corp.home.net From: "Mike St. Johns" Subject: Re: comments/questions for Subscriber Management MIB Cc: ipcdn@terayon.com, milu@cisco.com, apalmer@cisco.com, "Siripunkaw, Pak" In-Reply-To: <4.1.20000228084058.0098ff00@cliffie.ne.arris-i.com> References: <200002240425.UAA12711@paleale.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipcdn@terayon.com Precedence: bulk Reply-To: ipcdn@terayon.com At 05:53 AM 2/28/00 , Wilson Sawyer wrote: >Minnie - thanks for the comments. Replies interspersed. > >At 08:25 PM 2/23/00 -0800, Minnie Lu wrote: > >Hi, > > > > I have some comments/questions for Subscriber Management MIB > >(draft-ietf-ipcdn-subscriber-mib-00.txt) and appreciate any help in advance > >! If any of them are discussed before, sorry to repeat them and would > >appreciate letting me know the result. > > > > 1. In MIB module description, it says :"This will be rooted in > >experimental space with future transition to be incorporated into the cable > >device MIB." This MIB is in the MUST list of DOCSIS1.1 OSSI draft spec for > >CMTS. When will it happen and have a real root ? I'm going to stick it under the old Cable Device MIB OID tree. I'm waiting on assigning it until we get enough consensus that I don't have to deal with having to do the formal MIB change things (e.g. having to deprecate objects, obsolete them, etc so that OIDs don't get duplicated). >I don't have a good answer for you. Mike? > > > 2. docsSubMgtCpeControlMaxCpeIp has the range (0..16). To me, this > >implies that the max CPE IP in the provisioning object is 16. But, CPE IP > >can be "learned", so > > a) if the docsSubMgtCpeControlActive is true, the number of entries in > >docsSubMgtCpeIpTable could NOT be more than docsSubMgtCpeControlMaxCpeIp > >which max is16. Right ? No. MaxCpeIp applies to learned entries only. If you're already at max or above, you can't learn any more, but you can have your table entry modified to add new addresses. The reason you can't have more than 16 entries is because the index value of docsSubMgtCpeIpTable (e.g. the Index value) is (1..16) > > b) if the docsSubMgtCpeControlActive is false, the number of entries in > >docsSubMgtCpeIpTable could be more than 16. Right ? Nope - see above. The index range for the table controls this. > > c) Since docsSubMgtCpeControlActive is RW, if a user set it to false > from > >true, and at that moment, there are more than 16 entries in > >docsSubMgtCpeIpTable already, does it mean no more learned CPE IP ? But the > >existing CPE IP are still kept in the table, right ? Right. Except that 16 is the max. >I would answer that (a), (b), and (c) are correct as you've stated. In the >next >draft, the limit of '16' will be removed from the mib. Hmm? Index objects are required to have a range value. Do you want to change the range? >Your interpretation of (d) is reasonable, but maybe getting into >implementation >detail. Do you think we need to state this in the MIB? > > > > > 3. comment: docsSubMgtCpeControlLearnable: > > a) "If this is set to true, up to MaxCpeIp Address are learned > related to > >this CM." Would it be better to say "If this is set to true, up to number > >of docsSubMgtCpeControlMaxCpeIp Address can be learned related to this >CM." ? > >Your wording is probably clearer, but is there a substantive point that I'm >missing? I think her point is one implies you can learn N addresses, the other implies you can learn N - currentNumAddresses. E.g. if you've got 5 addresses already that have been SET (rather than learned), then you can still learn N addresses even if N is less than 5. I'd suggest changing to her language to keep the questions down. > > b) Also please add explanation of "learned" (what does it mean 'learned' > >?) since in the MIB definition, this is the first time the word 'learn' is > >mentioned. > > c) What if this is set to false ? Please explain more for false > condition. > >Acknowledged. will address in next draft. We don't want to go too far, though, >in defining 'learned', since we want to leave open a variety of learning >mechanisms at the CMTS. Actually, I don't think we want to leave this open. I'd rather make it clear we mean you learn based on the source addresses of the IP packets sent upstream from any given modem. > > 4. docsSubMgtPktFilterIndex: in the description of > >docsSubMgtPktFilterTable, it says that "no more than 20 classifiers", does > >it mean the FilterIndex is 1 .. 20 ? Need a range for it ? > >will be fixed in next draft. The limit has been removed per Guenter's >suggestion. *sigh* Indexes require a range. I don't mind making it larger than 20, but that was also a minimum. > > 5. docsSubMgtCmFilterDownstream (same for docsSubMgtCmFilterUpstream) > could > >be set to the default which could be 0 upon the initial CMTS >initialization. > > a) What does it mean for the value 0 here ? > > b) Also it is RW, could a user set the value to 0 on purposely ? > >(Same questions for docsSubMgtCmFilterDownDefault and > >docsSubMgtCmFilterUpDefault). > >I'll look at this. You can set the object to any valid value. However, that value might not map to a given filter set. By SNMP definition, the filter set can't have an index with a value of 0 so the default of 0 means it matches no filters. > > Thanks a lot for your help again in advance ! > > Minnie > > > > > >Wilson Sawyer wsawyer@ieee.org >Arris Interactive (978) 946 4711 >6 Riverside Drive fax (978) 946 4900 >Andover, MA 01810