The MIB module for monitoring and controlling PMIPv6 entities.
Copyright (c) 2012 IETF Trust and the persons identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info).
This object indicates the PMIPv6 functions that are supported by this managed entity. Multiple Proxy Mobile IPv6 functions may be supported by a single entity. mobilityAccessGateway(0) indicates the availability of the mobility access gateway function. localMobilityAnchor(1) indicates the availability of the local mobility anchor function. Reference: RFC 6275: Sections 3.2, 4.1
pmip6MobileNodeGeneratedTimestampInUse
1.3.6.1.2.1.206.1.1.3.1
TruthValue1 = true2 = falseRepresents a boolean value. · Integer32
This flag indicates whether or not the MN-generated timestamp mechanism is in use in that Proxy Mobile IPv6 domain. true(1) indicates that the local mobility anchors and mobile access gateways in that Proxy Mobile IPv6 domain apply the MN-generated timestamp considerations. false(0) indicates that the MN-generated timestamp mechanism is not in use in that Proxy Mobile IPv6 domain. The default value for this flag is 'false'. Reference: RFC 5213: Sections 5.5, 9.3
pmip6FixedMagLinkLocalAddressOnAllAccessLinksType
1.3.6.1.2.1.206.1.1.3.2
InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address.
unknown(0) An unknown address type. This value MUST
be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below.
ipv4(1) An IPv4 address as defined by the
InetAddressIPv4 textual convention.
ipv6(2) An IPv6 address as defined by the
InetAddressIPv6 textual convention.
ipv4z(3) A non-global IPv4 address including a zone
index as defined by the InetAddressIPv4z textual convention.
ipv6z(4) A non-global IPv6 address including a zone
index as defined by the InetAddressIPv6z textual convention.
dns(16) A DNS domain name as defined by the
InetAddressDNS textual convention.
Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType.
To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation.
Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32
The InetAddressType of the pmip6FixedMagLinkLocalAddressOnAllAccessLinks that follows.
pmip6FixedMagLinkLocalAddressOnAllAccessLinks
1.3.6.1.2.1.206.1.1.3.3
InetAddressDenotes a generic Internet address.
An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row.
The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error.
When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING
This variable indicates the link-local address value that all the mobile access gateways should use on any of the access links shared with any of the mobile nodes in that Proxy Mobile IPv6 domain. If this variable is initialized with all zeroes, it implies that the use of fixed link-local address mode is not enabled for that Proxy Mobile IPv6 domain. Reference: RFC 5213: Sections 2.2, 6.8, 6.9.1.1, 6.9.3, 9.3
pmip6FixedMagLinkLayerAddressOnAllAccessLinks
1.3.6.1.2.1.206.1.1.3.4
PhysAddressRepresents media- or physical-level addresses. · OCTET STRING · hint 1x:
This variable indicates the link-layer address value that all the mobile access gateways should use on any of the access links shared with any of the mobile nodes in that Proxy Mobile IPv6 domain. For access technologies where there is no link-layer address, this variable MUST be initialized with all zeroes. Reference: RFC 5213: Sections 6.9.3, 9.3
pmip6MissingMnIdentifierOption
1.3.6.1.2.1.206.1.1.4.1.1
Counter32
Total number of Proxy Binding Update messages rejected by the local mobility anchor with status code in the Binding Acknowledgement message indicating 'Missing mobile node identifier option' (Code 160).
Discontinuities in the value of this counter can occur at re-initialization of the mobile router, and at other times as indicated by the value of pmip6CounterDiscontinuityTime. Reference: RFC 5213: Sections 5.3.1, 8.9
pmip6MagNotAuthorizedForProxyReg
1.3.6.1.2.1.206.1.1.4.1.2
Counter32
Total number of Proxy Binding Update messages rejected by the local mobility anchor with status code in the Binding Acknowledgement message indicating 'Not authorized to send Proxy Binding Updates' (Code 154).
Discontinuities in the value of this counter can occur at re-initialization of the mobile router, and at other times as indicated by the value of pmip6CounterDiscontinuityTime. Reference: RFC 5213: Sections 5.3.1, 8.9
pmip6NotLMAForThisMobileNode
1.3.6.1.2.1.206.1.1.4.1.3
Counter32
Total number of Proxy Binding Update messages rejected by the local mobility anchor with status code in the Binding Acknowledgement message indicating 'Not local mobility anchor for this mobile node' (Code 153).
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of pmip6CounterDiscontinuityTime. Reference: RFC 5213: Sections 5.3.1, 8.9
pmip6ProxyRegNotEnabled
1.3.6.1.2.1.206.1.1.4.1.4
Counter32
Total number of Proxy Binding Update messages rejected by the local mobility anchor with status code in the Binding Acknowledgement message indicating 'Proxy Registration not enabled' (Code 152). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of pmip6CounterDiscontinuityTime. Reference: RFC 5213: Sections 5.3.1, 6.9.1.2, 8.9
pmip6MissingHomeNetworkPrefixOption
1.3.6.1.2.1.206.1.1.4.1.5
Counter32
Total number of Proxy Binding Update messages rejected by the local mobility anchor with status code in the Binding Acknowledgement message indicating 'Missing home network prefix option' (Code 158). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of pmip6CounterDiscontinuityTime. Reference: RFC 5213: Sections 5.3.1, 8.9
pmip6MissingHandOffIndicatorOption
1.3.6.1.2.1.206.1.1.4.1.6
Counter32
Total number of Proxy Binding Update messages rejected by the local mobility anchor with status code in the Binding Acknowledgement message indicating 'Missing handoff indicator option' (Code 161). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of pmip6CounterDiscontinuityTime. Reference: RFC 5213: Sections 5.3.1, 8.9
pmip6MissingAccessTechTypeOption
1.3.6.1.2.1.206.1.1.4.1.7
Counter32
Total number of Proxy Binding Update messages rejected by the local mobility anchor with status code in the Binding Acknowledgement message indicating 'Missing access technology type option' (Code 162). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of pmip6CounterDiscontinuityTime. Reference: RFC 5213: Sections 5.3.1, 8.9
pmip6NotAuthorizedForHomeNetworkPrefix
1.3.6.1.2.1.206.1.1.4.1.8
Counter32
Total number of Proxy Binding Update messages rejected by the local mobility anchor with status code in the Binding Acknowledgement message indicating 'Mobile node not authorized for one or more of the requesting home network prefixes' (Code 155).
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of pmip6CounterDiscontinuityTime. Reference: RFC 5213: Sections 5.3.2, 6.9.1.2, 8.9
pmip6TimestampMismatch
1.3.6.1.2.1.206.1.1.4.1.9
Counter32
Total number of Proxy Binding Update messages rejected by the local mobility anchor with status code in the Binding Acknowledgement message indicating 'Invalid timestamp value (the clocks are out of sync)' (Code 156). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of pmip6CounterDiscontinuityTime. Reference: RFC 5213: Sections 5.5, 6.9.1.2, 8.9
pmip6TimestampLowerThanPrevAccepted
1.3.6.1.2.1.206.1.1.4.1.10
Counter32
Total number of Proxy Binding Update messages rejected by the local mobility anchor with status code in the Binding Acknowledgement message indicating 'The timestamp value is lower than the previously accepted value' (Code 157). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of pmip6CounterDiscontinuityTime. Reference: RFC 5213: Sections 5.5, 6.9.1.2, 8.9
pmip6BcePbuPrefixSetDoNotMatch
1.3.6.1.2.1.206.1.1.4.1.11
Counter32
Total number of Proxy Binding Update messages rejected by the local mobility anchor with status code in the Binding Acknowledgement message indicating 'All the home network prefixes listed in the Binding Cache entry do not match all the prefixes in the received Proxy Binding Update' (Code 159). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of pmip6CounterDiscontinuityTime. Reference: RFC 5213: Sections 5.4.1.1, 8.9
pmip6InitialBindingRegistrations
1.3.6.1.2.1.206.1.1.4.1.12
Counter32
Total number of Proxy Binding Update messages that newly creates the Binding Cache entry. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of pmip6CounterDiscontinuityTime. Reference: RFC 5213: Sections 5.3.2
pmip6BindingLifeTimeExtensionNoHandOff
1.3.6.1.2.1.206.1.1.4.1.13
Counter32
Total number of Proxy Binding Update messages for extending the binding lifetime, received from the same mobile access gateway that last updated the binding. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of pmip6CounterDiscontinuityTime. Reference: RFC 5213: Sections 5.3.3
pmip6BindingLifeTimeExtensionAfterHandOff
1.3.6.1.2.1.206.1.1.4.1.14
Counter32
Total number of Proxy Binding Update messages for extending the binding lifetime, received from a new mobile access gateway where the mobile node's mobility session is handed off. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of pmip6CounterDiscontinuityTime. Reference: RFC 5213: Sections 5.3.4
pmip6BindingDeRegistrations
1.3.6.1.2.1.206.1.1.4.1.15
Counter32
Total number of Proxy Binding Update messages with the lifetime value of zero. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of pmip6CounterDiscontinuityTime. Reference: RFC 5213: Sections 5.3.5
pmip6BindingBindingAcks
1.3.6.1.2.1.206.1.1.4.1.16
Counter32
Total number of Proxy Binding Acknowledgement messages. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of pmip6CounterDiscontinuityTime. Reference: RFC 5213: Sections 5.3.5
pmip6CounterDiscontinuityTime
1.3.6.1.2.1.206.1.1.4.1.17
TimeStampThe value of the sysUpTime object at which a specific occurrence happened. The specific occurrence must be
defined in the description of any object defined using this type.
If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all TimeStamp objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment around to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks
The value of sysUpTime on the most recent occasion at which any one or more of this PMIPv6 entity's global counters, viz., counters with OID prefix 'pmip6BindingRegCounters' suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this object will have a zero value.
pmip6MagStatus
1.3.6.1.2.1.206.1.2.1.1
INTEGER1 = enabled2 = disabled · Integer32
This object indicates whether the PMIPv6 mobile access gateway function is enabled for the managed entity.
Changing the status from enabled(1) to disabled(2) will terminate the PMIPv6 mobile access gateway function. On the other hand, changing the status from disabled(2) to enabled(1) will start the PMIPv6 mobile access gateway function.
The value of this object MUST remain unchanged across reboots of the managed entity.
pmip6MagEnableMagLocalRouting
1.3.6.1.2.1.206.1.2.2.1
TruthValue1 = true2 = falseRepresents a boolean value. · Integer32
This flag indicates whether or not the mobile access gateway is allowed to enable local routing of the traffic exchanged between a visiting mobile node and a correspondent node that is locally connected to one of the interfaces of the mobile access gateway. The correspondent node can be another visiting mobile node as well, or a local fixed node. true(1) indicates that the mobile access gateway routes the traffic locally. false(0) indicates that the mobile access gateway reverse tunnels all the traffic to the mobile node's local mobility anchor.
The default value for this flag is 'false'. Reference: RFC 5213: Section 9.2
pmip6LmaStatus
1.3.6.1.2.1.206.1.3.1.1
INTEGER1 = enabled2 = disabled · Integer32
This object indicates whether the PMIPv6 local mobility anchor function is enabled for the managed entity.
Changing the status from enabled(1) to disabled(2) will terminate the PMIPv6 local mobility anchor function. On the other hand, changing the status from disabled(2) to enabled(1) will start the PMIPv6 local mobility anchor function.
The value of this object MUST remain unchanged across reboots of the managed entity.
pmip6LmaMinDelayBeforeBCEDelete
1.3.6.1.2.1.206.1.3.2.1
Integer32 (1..65535) · milliseconds
This variable specifies the length of time in milliseconds the local mobility anchor MUST wait before it deletes a Binding Cache entry of a mobile node, upon receiving a Proxy Binding Update message from a mobile access gateway with a lifetime value of 0. During this wait time, if the local mobility anchor receives a Proxy Binding Update for the same mobility binding, with a lifetime value greater than 0, then it must update the Binding Cache entry with the accepted binding values. By the end of this wait time, if the local mobility anchor did not receive any valid Proxy Binding Update message for that mobility binding, it MUST delete the Binding Cache entry. This delay essentially ensures that a mobile node's Binding Cache entry is not deleted too quickly and allows some time for the new mobile access gateway to complete the signaling for the mobile node. The default value for this variable is 10000 milliseconds. Reference: RFC 5213: Sections 5.3.5, 9.1
pmip6LmaMaxDelayBeforeNewBCEAssign
1.3.6.1.2.1.206.1.3.2.2
Integer32 (1..65535) · milliseconds
This variable specifies the length of time in milliseconds the local mobility anchor MUST wait for the de-registration message for an existing mobility session before it decides to create a new mobility session.
The default value for this variable is 1500 milliseconds. Note that there is a dependency between this value and the values used in the retransmission algorithm for Proxy Binding Updates. The retransmissions need to happen before MaxDelayBeforeNewBCEAssign runs out, as otherwise there are situations where a de-registration from a previous mobile access gateway may be lost, and the local mobility anchor creates, needlessly, a new mobility session and new prefixes for the mobile node. However, this affects situations where there is no information from the lower layers about the type of a handoff or other parameters that can be used for identifying the mobility session. Reference: RFC 5213: Sections 5.4.1.2, 5.4.1.3, 9.1
pmip6LmaTimestampValidityWindow
1.3.6.1.2.1.206.1.3.2.3
Integer32 (1..65535) · milliseconds
This variable specifies the maximum length of time difference in milliseconds between the timestamp in the received Proxy Binding Update message and the current time of day on the local mobility anchor that is allowed by the local mobility anchor for the received message to be considered valid. The default value for this variable is 300 milliseconds. This variable must be adjusted to suit the deployments. Reference: RFC 5213: Sections 5.5, 9.1
This table models the Binding Cache on the local mobility anchor.
Entries from the table are deleted as the lifetime of the binding expires.
Entries in this table are not required to survive a reboot of the managed entity. Reference: RFC 6275: Sections 4.5, 9.1, 10.1 RFC 5213: Section 5.1
InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address.
unknown(0) An unknown address type. This value MUST
be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below.
ipv4(1) An IPv4 address as defined by the
InetAddressIPv4 textual convention.
ipv6(2) An IPv6 address as defined by the
InetAddressIPv6 textual convention.
ipv4z(3) A non-global IPv4 address including a zone
index as defined by the InetAddressIPv4z textual convention.
ipv6z(4) A non-global IPv6 address including a zone
index as defined by the InetAddressIPv6z textual convention.
dns(16) A DNS domain name as defined by the
InetAddressDNS textual convention.
Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType.
To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation.
Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32
The InetAddressType of the mip6BindingHomeAddress that follows.
mip6BindingHomeAddress
InetAddressDenotes a generic Internet address.
An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row.
The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error.
When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING
The home address of the mobile node corresponding to the Binding Cache entry. This field is used as the key for searching the mobile node's current care-of address in the Binding Cache.
The type of the address represented by this object is specified by the corresponding mip6BindingHomeAddressType object. Reference: RFC 3775 : Section 9.1
pmip6BindingPBUFlag
1.3.6.1.2.1.206.1.1.2.1.1.1
TruthValue1 = true2 = falseRepresents a boolean value. · Integer32
true(1) indicates that the local mobility anchor accepted the binding update with Proxy Registration Flag from a mobile access gateway. false(0) implies that the binding cache is from a mobile node. In this case, the remaining objects will not be accessible. Reference: RFC 5213: Sections 5.1, 8.1
pmip6BindingMnIndex
1.3.6.1.2.1.206.1.1.2.1.1.2
Pmip6MnIndexA unique integer value, greater than zero, assigned to each mobile node that is currently attached to the Proxy Mobile IPv6 domain by the management system. It is recommended that the values are assigned in a monotonically increasing order starting from 1. It may wrap after reaching its maximum value. The value for each mobile node must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. (1..4294967295) · Unsigned32 · hint d
An index to the identifier of the registered mobile node. Reference: RFC 5213: Sections 2.2, 5.1, 8.1 RFC 4283: Section 3
pmip6BindingMnLLIndex
1.3.6.1.2.1.206.1.1.2.1.1.3
Pmip6MnLLIndexA unique integer value, greater than zero, assigned to each interface of a mobile node that is currently attached to the Proxy Mobile IPv6 domain by the management system. It is recommended that the values are assigned in a monotonically increasing order starting from 1. It may wrap after reaching its maximum value. The value for each interface of a mobile node must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. (1..4294967295) · Unsigned32 · hint d
The index to the link-layer identifier of the mobile node's connected interface on the access link. Reference: RFC 5213: Sections 2.2, 5.1, 8.1
pmip6BindingMagLinkLocalAddressType
1.3.6.1.2.1.206.1.1.2.1.1.4
InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address.
unknown(0) An unknown address type. This value MUST
be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below.
ipv4(1) An IPv4 address as defined by the
InetAddressIPv4 textual convention.
ipv6(2) An IPv6 address as defined by the
InetAddressIPv6 textual convention.
ipv4z(3) A non-global IPv4 address including a zone
index as defined by the InetAddressIPv4z textual convention.
ipv6z(4) A non-global IPv6 address including a zone
index as defined by the InetAddressIPv6z textual convention.
dns(16) A DNS domain name as defined by the
InetAddressDNS textual convention.
Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType.
To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation.
Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32
The InetAddressType of the pmip6BindingMagLinkLocalAddress that follows.
pmip6BindingMagLinkLocalAddress
1.3.6.1.2.1.206.1.1.2.1.1.5
InetAddressDenotes a generic Internet address.
An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row.
The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error.
When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING
The link-local address of the mobile access gateway on the point-to-point link shared with the mobile node. This is generated by the local mobility anchor after accepting the initial Proxy Binding Update message. This is the address that is present in the Link-local Address option of the corresponding Proxy Binding Acknowledgement message. Reference: RFC 5213: Sections 5.1, 6.9.1.2, 8.2
pmip6BindingTunnelIfIdentifier
1.3.6.1.2.1.206.1.1.2.1.1.6
Ipv6AddressIfIdentifierTCThis data type is used to model IPv6 address interface identifiers. This is a binary string of up to 8 octets in network byte-order. SIZE (0..8) · OCTET STRING · hint 2x:
The tunnel interface identifier (tunnel-if-id) of the bidirectional tunnel between the local mobility anchor and the mobile access gateway where the mobile node is currently anchored. This is internal to the local mobility anchor. The tunnel interface identifier is acquired during the tunnel creation. Reference: RFC 5213: Sections 5.1, 8.1
pmip6BindingMnInterfaceATT
1.3.6.1.2.1.206.1.1.2.1.1.7
Pmip6MnInterfaceATT0 = reserved1 = logicalNetworkInterface2 = pointToPointInterface3 = ethernet4 = wirelessLan5 = wimax6 = threeGPPGERAN7 = threeGPPUTRAN8 = threeGPPEUTRAN9 = threeGPP2eHRPD10 = threeGPP2HRPD11 = threeGPP21xRTT12 = threeGPP2UMBThe object specifies the access technology that connects the mobile node to the access link on the mobile access gateway. The enumerated values and the corresponding access technology are as follows:
reserved (0): Reserved (Not used)
logicalNetworkInterface (1): Logical network interface
pointToPointInterface (2): Point-to-point interface
ethernet (3): Ethernet interface
wirelessLan (4): Wireless LAN interface
wimax (5): Wimax interface
threeGPPGERAN (6): 3GPP GERAN
threeGPPUTRAN (7): 3GPP UTRAN
threeGPPEUTRAN (8): 3GPP E-UTRAN
threeGPP2eHRPD (9): 3GPP2 eHRPD
threeGPP2HRPD (10): 3GPP2 HRPD
threeGPP21xRTT (11): 3GPP2 1xRTT
threeGPP2UMB (12): 3GPP2 UMBReference: RFC 5213: Section 8.5, Mobile IPv6 parameters registry on http://www.iana.org/mobility-parameters · Integer32
The access technology type by which the mobile node is currently attached. This is obtained from the Access Technology Type option, present in the Proxy Binding Update message. Reference: RFC 5213: Sections 5.1, 8.1
pmip6BindingTimeRecentlyAccepted
1.3.6.1.2.1.206.1.1.2.1.1.8
Pmip6TimeStamp64A 64-bit unsigned integer field containing a timestamp. The value indicates the elapsed time since January 1, 1970, 00:00 UTC, by using a fixed-point format. In this format, the integer number of seconds is contained in the first 48 bits of the field, and the remaining 16 bits indicate the number of 1/65536 fractions of a second.Reference: RFC 5213: Section 8.8 SIZE (8) · OCTET STRING · hint 6d:2d
The 64-bit timestamp value of the most recently accepted Proxy Binding Update message sent for this mobile node. This is the time of day on the local mobility anchor, when the message was received. If the Timestamp option is not present in the Proxy Binding Update message (i.e., when the sequence number based scheme is in use), the value MUST be initialized with all zeroes. Reference: RFC 5213: Sections 5.1, 8.1
pmip6MagProxyCOATable
1.3.6.1.2.1.206.1.2.1.2
Index: pmip6MagProxyCOAType · pmip6MagProxyCOA
This table models the Proxy Care-of Addresses configured on the egress interfaces of the mobile access gateway. This address is the transport endpoint of the tunnel between the local mobility anchor and the mobile access gateway.
Entries in this table are not required to survive a reboot of the managed entity. Reference: RFC 5213: Sections 2.2, 6.10
pmip6MagProxyCOAType
1.3.6.1.2.1.206.1.2.1.2.1.1
InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address.
unknown(0) An unknown address type. This value MUST
be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below.
ipv4(1) An IPv4 address as defined by the
InetAddressIPv4 textual convention.
ipv6(2) An IPv6 address as defined by the
InetAddressIPv6 textual convention.
ipv4z(3) A non-global IPv4 address including a zone
index as defined by the InetAddressIPv4z textual convention.
ipv6z(4) A non-global IPv6 address including a zone
index as defined by the InetAddressIPv6z textual convention.
dns(16) A DNS domain name as defined by the
InetAddressDNS textual convention.
Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType.
To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation.
Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32
The InetAddressType of the pmip6MagProxyCOA that follows.
pmip6MagProxyCOA
1.3.6.1.2.1.206.1.2.1.2.1.2
InetAddressDenotes a generic Internet address.
An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row.
The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error.
When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING
The Proxy-CoA configured on the egress interface of the mobile access gateway.
The type of the address represented by this object is specified by the corresponding pmip6MagProxyCOAType object. Reference: RFC 5213: Sections 2.2, 6.10
This object indicates the state of the Proxy-CoA:
unknown -- The state of the Proxy-CoA
cannot be determined.
activated -- The Proxy-CoA is ready to establish
a tunnel. This state SHOULD be indicated when the MAG is up but has no mobile node.
tunneled -- Bidirectional tunnel is established
using the Proxy-CoA.
pmip6MagMnIdentifierTable
1.3.6.1.2.1.206.1.2.2.2
Index: pmip6MagBLMnIndex
A table containing the identifiers of mobile nodes attached to the MAG. Entries in this table are not required to survive a reboot of the managed entity. Reference: RFC 5213: Sections 2.2, 6.1
pmip6MagMnIdentifier
1.3.6.1.2.1.206.1.2.2.2.1.1
Pmip6MnIdentifierThe identity of a mobile node in the Proxy Mobile IPv6 domain. This is the stable identifier of a mobile node that the mobility entities in a Proxy Mobile IPv6 domain can always acquire and use for predictably identifying a mobile node. Various forms of identifiers can be used to identify a mobile node (MN). Two examples are a Network Access Identifier (NAI) and an opaque identifier applicable to a particular application.Reference: RFC 4283: Section 3 SIZE (0..255) · OCTET STRING · hint 255a
The identity of a mobile node in the Proxy Mobile IPv6 domain. Reference: RFC 5213: Sections 2.2, 6.1
pmip6MagMnLLIdentifierTable
1.3.6.1.2.1.206.1.2.2.3
Index: pmip6MagBLMnIndex · pmip6MagBLMnLLIndex
A table containing the link-layer identifiers of the interfaces of the mobile nodes attached to the MAG. Entries in this table are not required to survive a reboot of the managed entity. Reference: RFC 5213: Sections 2.2, 6.1
pmip6MagMnLLIdentifier
1.3.6.1.2.1.206.1.2.2.3.1.1
Pmip6MnLLIdentifierAn identifier that identifies the attached interface of a mobile node.Reference: RFC 5213: Section 8.6 SIZE (0..255) · OCTET STRING · hint 255a
The link-layer identifier of the mobile node's connected interface on the access link. Reference: RFC 5213: Sections 2.2, 6.1
A table representing the home network prefixes assigned to the connected interfaces of mobile nodes attached to the MAG. Reference: RFC 5213: Sections 2, 6.1, 6.2
pmip6MagHomeNetworkPrefixType
1.3.6.1.2.1.206.1.2.2.4.1.1
InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address.
unknown(0) An unknown address type. This value MUST
be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below.
ipv4(1) An IPv4 address as defined by the
InetAddressIPv4 textual convention.
ipv6(2) An IPv6 address as defined by the
InetAddressIPv6 textual convention.
ipv4z(3) A non-global IPv4 address including a zone
index as defined by the InetAddressIPv4z textual convention.
ipv6z(4) A non-global IPv6 address including a zone
index as defined by the InetAddressIPv6z textual convention.
dns(16) A DNS domain name as defined by the
InetAddressDNS textual convention.
Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType.
To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation.
Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32
The InetAddressType of the pmip6MagHomeNetworkPrefix that follows.
pmip6MagHomeNetworkPrefix
1.3.6.1.2.1.206.1.2.2.4.1.2
InetAddressDenotes a generic Internet address.
An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row.
The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error.
When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING
The mobile network prefix that is delegated to the mobile node. The type of the address represented by this object is specified by the corresponding pmip6MagHomeNetworkPrefixType object. Reference: RFC 5213: Section 2
pmip6MagHomeNetworkPrefixLength
1.3.6.1.2.1.206.1.2.2.4.1.3
InetAddressPrefixLengthDenotes the length of a generic Internet network address prefix. A value of n corresponds to an IP address mask that has n contiguous 1-bits from the most significant bit (MSB), with all other bits set to 0.
An InetAddressPrefixLength value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddressPrefixLength textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddressPrefixLength textual convention, if they appear in the same logical row.
InetAddressPrefixLength values larger than the maximum length of an IP address for a specific InetAddressType are treated as the maximum significant value applicable for the InetAddressType. The maximum significant value is 32 for the InetAddressType 'ipv4(1)' and 'ipv4z(3)' and 128 for the InetAddressType 'ipv6(2)' and 'ipv6z(4)'. The maximum significant value for the InetAddressType 'dns(16)' is 0.
The value zero is object-specific and must be defined as part of the description of any object that uses this syntax. Examples of the usage of zero might include situations where the Internet network address prefix is unknown or does not apply.
The upper bound of the prefix length has been chosen to be consistent with the maximum size of an InetAddress. (0..2040) · Unsigned32 · hint d
The prefix length of the home network prefix.
pmip6MagHomeNetworkPrefixLifeTime
1.3.6.1.2.1.206.1.2.2.4.1.4
Unsigned32 · seconds
The lifetime parameter (in seconds) that will be advertised in Router Advertisements by the MAG for this home network prefix. Reference: RFC 5213: Sections 6.2, 6.7
This table corresponds to the Binding Update List (BL) that includes PMIPv6-related information and is maintained by the mobile access gateway. Entries from the table are deleted as the lifetime of the binding expires. Reference: RFC 6275: Sections 4.5, 11.1 RFC 5213: Section 6.1
InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address.
unknown(0) An unknown address type. This value MUST
be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below.
ipv4(1) An IPv4 address as defined by the
InetAddressIPv4 textual convention.
ipv6(2) An IPv6 address as defined by the
InetAddressIPv6 textual convention.
ipv4z(3) A non-global IPv4 address including a zone
index as defined by the InetAddressIPv4z textual convention.
ipv6z(4) A non-global IPv6 address including a zone
index as defined by the InetAddressIPv6z textual convention.
dns(16) A DNS domain name as defined by the
InetAddressDNS textual convention.
Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType.
To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation.
Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32
The InetAddressType of the mip6MnHomeAddress that follows.
mip6MnHomeAddress
InetAddressDenotes a generic Internet address.
An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row.
The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error.
When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING
A unicast routable address assigned to the mobile node. This is used as the 'permanent address' of the mobile node in the sense that it remains unchanged regardless of the mobile node's current point of attachment. If mobile node doesn't have a home address assigned yet, then this object will take the default 'unspecified' value ::0.
The type of the address represented by this object is specified by the corresponding mip6MnHomeAddressType object. Reference: RFC 3775 : Section 3.2
mip6MnBLNodeAddressType
InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address.
unknown(0) An unknown address type. This value MUST
be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below.
ipv4(1) An IPv4 address as defined by the
InetAddressIPv4 textual convention.
ipv6(2) An IPv6 address as defined by the
InetAddressIPv6 textual convention.
ipv4z(3) A non-global IPv4 address including a zone
index as defined by the InetAddressIPv4z textual convention.
ipv6z(4) A non-global IPv6 address including a zone
index as defined by the InetAddressIPv6z textual convention.
dns(16) A DNS domain name as defined by the
InetAddressDNS textual convention.
Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType.
To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation.
Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32
The InetAddressType of the mip6MnBLNodeAddress that follows.
mip6MnBLNodeAddress
InetAddressDenotes a generic Internet address.
An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row.
The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error.
When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING
The address of the agent as used in the destination address of the Binding Update. The agent may be a home agent or a correspondent node.
The type of the address represented by this object is specified by the corresponding mip6MnBLNodeAddressType object. Reference: RFC 3775 : Section 11.1
pmip6MagBLFlag
1.3.6.1.2.1.206.1.2.3.1.1.1
TruthValue1 = true2 = falseRepresents a boolean value. · Integer32
true(1) indicates that the mobile access gateway sent the Proxy Binding Update with Proxy Registration Flag that indicates to the local mobility anchor that the registration is the Proxy Binding Update and is from a mobile access gateway. false(0) implies that the mobile access gateway is behaving as a simple mobile node. Reference: RFC 5213: Section 8.1
pmip6MagBLMnIndex
1.3.6.1.2.1.206.1.2.3.1.1.2
Pmip6MnIndexA unique integer value, greater than zero, assigned to each mobile node that is currently attached to the Proxy Mobile IPv6 domain by the management system. It is recommended that the values are assigned in a monotonically increasing order starting from 1. It may wrap after reaching its maximum value. The value for each mobile node must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. (1..4294967295) · Unsigned32 · hint d
The index to the identifier of the attached mobile node in the pmip6MagMnIdentifierTable. Reference: RFC 5213: Sections 2.2, 6.1, 8.1
pmip6MagBLMnLLIndex
1.3.6.1.2.1.206.1.2.3.1.1.3
Pmip6MnLLIndexA unique integer value, greater than zero, assigned to each interface of a mobile node that is currently attached to the Proxy Mobile IPv6 domain by the management system. It is recommended that the values are assigned in a monotonically increasing order starting from 1. It may wrap after reaching its maximum value. The value for each interface of a mobile node must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. (1..4294967295) · Unsigned32 · hint d
The index to the link-layer identifier of the mobile node's connected interface in the pmip6MagMnLLIdentifierTable. Reference: RFC 5213: Sections 2.2, 6.1, 8.1
pmip6MagBLMagLinkLocalAddressType
1.3.6.1.2.1.206.1.2.3.1.1.4
InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address.
unknown(0) An unknown address type. This value MUST
be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below.
ipv4(1) An IPv4 address as defined by the
InetAddressIPv4 textual convention.
ipv6(2) An IPv6 address as defined by the
InetAddressIPv6 textual convention.
ipv4z(3) A non-global IPv4 address including a zone
index as defined by the InetAddressIPv4z textual convention.
ipv6z(4) A non-global IPv6 address including a zone
index as defined by the InetAddressIPv6z textual convention.
dns(16) A DNS domain name as defined by the
InetAddressDNS textual convention.
Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType.
To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation.
Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32
The InetAddressType of the pmip6MagBLMagLinkLocalAddress that follows.
pmip6MagBLMagLinkLocalAddress
1.3.6.1.2.1.206.1.2.3.1.1.5
InetAddressDenotes a generic Internet address.
An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row.
The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error.
When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING
The link-local address of the mobile access gateway on the access link shared with the mobile node. This is the address that is present in the Link-local Address option of the corresponding Proxy Binding Update message. Reference: RFC 3963: Sections 4.1, 5.1
pmip6MagBLMagIfIdentifierToMn
1.3.6.1.2.1.206.1.2.3.1.1.6
Ipv6AddressIfIdentifierTCThis data type is used to model IPv6 address interface identifiers. This is a binary string of up to 8 octets in network byte-order. SIZE (0..8) · OCTET STRING · hint 2x:
The interface identifier (if-id) of the point-to-point link between the mobile node and the mobile access gateway. This is internal to the mobile access gateway and is used to associate the Proxy Mobile IPv6 tunnel to the access link where the mobile node is attached. Reference: RFC 5213: Sections 6.1, 8.1
pmip6MagBLTunnelIfIdentifier
1.3.6.1.2.1.206.1.2.3.1.1.7
Ipv6AddressIfIdentifierTCThis data type is used to model IPv6 address interface identifiers. This is a binary string of up to 8 octets in network byte-order. SIZE (0..8) · OCTET STRING · hint 2x:
The tunnel interface identifier (tunnel-if-id) of the bidirectional tunnel between the mobile node's local mobility anchor and the mobile access gateway. This is internal to the mobile access gateway. The tunnel interface identifier is acquired during the tunnel creation. Reference: RFC 5213: Sections 6.1, 8.1
pmip6MagBLMnInterfaceATT
1.3.6.1.2.1.206.1.2.3.1.1.8
Pmip6MnInterfaceATT0 = reserved1 = logicalNetworkInterface2 = pointToPointInterface3 = ethernet4 = wirelessLan5 = wimax6 = threeGPPGERAN7 = threeGPPUTRAN8 = threeGPPEUTRAN9 = threeGPP2eHRPD10 = threeGPP2HRPD11 = threeGPP21xRTT12 = threeGPP2UMBThe object specifies the access technology that connects the mobile node to the access link on the mobile access gateway. The enumerated values and the corresponding access technology are as follows:
reserved (0): Reserved (Not used)
logicalNetworkInterface (1): Logical network interface
pointToPointInterface (2): Point-to-point interface
ethernet (3): Ethernet interface
wirelessLan (4): Wireless LAN interface
wimax (5): Wimax interface
threeGPPGERAN (6): 3GPP GERAN
threeGPPUTRAN (7): 3GPP UTRAN
threeGPPEUTRAN (8): 3GPP E-UTRAN
threeGPP2eHRPD (9): 3GPP2 eHRPD
threeGPP2HRPD (10): 3GPP2 HRPD
threeGPP21xRTT (11): 3GPP2 1xRTT
threeGPP2UMB (12): 3GPP2 UMBReference: RFC 5213: Section 8.5, Mobile IPv6 parameters registry on http://www.iana.org/mobility-parameters · Integer32
The type of the access technology by which the mobile node is currently attached to the mobile access gateway. Reference: RFC 5213: Sections 6.9.1.1, 6.9.1.5, 8.1
pmip6MagBLTimeRecentlyAccepted
1.3.6.1.2.1.206.1.2.3.1.1.9
Pmip6TimeStamp64A 64-bit unsigned integer field containing a timestamp. The value indicates the elapsed time since January 1, 1970, 00:00 UTC, by using a fixed-point format. In this format, the integer number of seconds is contained in the first 48 bits of the field, and the remaining 16 bits indicate the number of 1/65536 fractions of a second.Reference: RFC 5213: Section 8.8 SIZE (8) · OCTET STRING · hint 6d:2d
The 64-bit timestamp value of the most recently accepted Proxy Binding Update message sent for this mobile node. This is the time of day on the mobile access gateway, when the Proxy Binding Acknowledgement message with the Status field set to 0 was received. If the Timestamp option is not present in the Proxy Binding Update message (i.e., when the sequence-number-based scheme is in use), the value MUST be initialized with all zeroes. Reference: RFC 5213: Sections 5.1, 8.1
pmip6MagMnProfileTable
1.3.6.1.2.1.206.1.2.3.2
Index: pmip6MagProfMnIndex
This table corresponds to the mobile node's policy profile that includes the essential operational parameters that are required by the network entities for managing the mobile node's mobility service. It contains policy profiles of mobile nodes that are connected to the mobile access gateway. Entries in this table are not required to survive a reboot of the managed entity. Reference: RFC 5213: Section 6.2
pmip6MagProfMnIndex
1.3.6.1.2.1.206.1.2.3.2.1.1
Pmip6MnIndexA unique integer value, greater than zero, assigned to each mobile node that is currently attached to the Proxy Mobile IPv6 domain by the management system. It is recommended that the values are assigned in a monotonically increasing order starting from 1. It may wrap after reaching its maximum value. The value for each mobile node must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. (1..4294967295) · Unsigned32 · hint d
The index for a mobile node in the Proxy Mobile IPv6 domain.
pmip6MagProfMnIdentifier
1.3.6.1.2.1.206.1.2.3.2.1.2
Pmip6MnIdentifierThe identity of a mobile node in the Proxy Mobile IPv6 domain. This is the stable identifier of a mobile node that the mobility entities in a Proxy Mobile IPv6 domain can always acquire and use for predictably identifying a mobile node. Various forms of identifiers can be used to identify a mobile node (MN). Two examples are a Network Access Identifier (NAI) and an opaque identifier applicable to a particular application.Reference: RFC 4283: Section 3 SIZE (0..255) · OCTET STRING · hint 255a
The identity of a mobile node in the Proxy Mobile IPv6 domain. Reference: RFC 5213: Section 2.2
pmip6MagProfMnLocalMobilityAnchorAddressType
1.3.6.1.2.1.206.1.2.3.2.1.3
InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address.
unknown(0) An unknown address type. This value MUST
be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below.
ipv4(1) An IPv4 address as defined by the
InetAddressIPv4 textual convention.
ipv6(2) An IPv6 address as defined by the
InetAddressIPv6 textual convention.
ipv4z(3) A non-global IPv4 address including a zone
index as defined by the InetAddressIPv4z textual convention.
ipv6z(4) A non-global IPv6 address including a zone
index as defined by the InetAddressIPv6z textual convention.
dns(16) A DNS domain name as defined by the
InetAddressDNS textual convention.
Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType.
To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation.
Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32
The InetAddressType of the pmip6MagMnLocalMobilityAnchorAddress that follows.
pmip6MagProfMnLocalMobilityAnchorAddress
1.3.6.1.2.1.206.1.2.3.2.1.4
InetAddressDenotes a generic Internet address.
An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row.
The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error.
When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING
The global address that is configured on the interface of the local mobility anchor and is the transport endpoint of the bidirectional tunnel established between the local mobility anchor and the mobile access gateway. This is the address to which the mobile access gateway sends the Proxy Binding Update messages. Reference: RFC 5213: Section 2.2
pmip6LmaLMAATable
1.3.6.1.2.1.206.1.3.1.2
Index: pmip6LmaLMAAType · pmip6LmaLMAA
This table models the LMA Addresses configured on the local mobility anchor. Each LMA Address acts as a transport endpoint of the tunnel between the local mobility anchor and the mobile access gateway and is the transport endpoint of the tunnel between the local mobility anchor and the mobile access gateway.
Entries in this table are not required to survive a reboot of the managed entity. Reference: RFC 5213: Sections 2.2, 5.6
pmip6LmaLMAAType
1.3.6.1.2.1.206.1.3.1.2.1.1
InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address.
unknown(0) An unknown address type. This value MUST
be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below.
ipv4(1) An IPv4 address as defined by the
InetAddressIPv4 textual convention.
ipv6(2) An IPv6 address as defined by the
InetAddressIPv6 textual convention.
ipv4z(3) A non-global IPv4 address including a zone
index as defined by the InetAddressIPv4z textual convention.
ipv6z(4) A non-global IPv6 address including a zone
index as defined by the InetAddressIPv6z textual convention.
dns(16) A DNS domain name as defined by the
InetAddressDNS textual convention.
Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType.
To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation.
Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32
The InetAddressType of the pmip6LmaLMAA that follows.
pmip6LmaLMAA
1.3.6.1.2.1.206.1.3.1.2.1.2
InetAddressDenotes a generic Internet address.
An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row.
The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error.
When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING
The LMAA configured on the local mobility anchor.
The type of the address represented by this object is specified by the corresponding pmip6LmaLMAAType object. Reference: RFC 5213: Sections 2.2, 5.6
This object indicates the state of the LMAA:
unknown -- The state of the LMAA
cannot be determined.
activated -- The LMAA is ready to establish
a tunnel.
tunneled -- The LMAA is used to set up the
bidirectional tunnel.
pmip6LmaMnIdentifierTable
1.3.6.1.2.1.206.1.3.2.4
Index: pmip6BindingMnIndex
A table containing the identifiers of mobile nodes served by the LMA. Entries in this table are not required to survive a reboot of the managed entity. Reference: RFC 5213: Sections 2, 6.1
pmip6LmaMnIdentifier
1.3.6.1.2.1.206.1.3.2.4.1.1
Pmip6MnIdentifierThe identity of a mobile node in the Proxy Mobile IPv6 domain. This is the stable identifier of a mobile node that the mobility entities in a Proxy Mobile IPv6 domain can always acquire and use for predictably identifying a mobile node. Various forms of identifiers can be used to identify a mobile node (MN). Two examples are a Network Access Identifier (NAI) and an opaque identifier applicable to a particular application.Reference: RFC 4283: Section 3 SIZE (0..255) · OCTET STRING · hint 255a
The identity of a mobile node in the Proxy Mobile IPv6 domain. Reference: RFC 5213: Section 2.2
A table containing the link-layer identifiers of the interfaces of the mobile nodes served by the LMA. Entries in this table are not required to survive a reboot of the managed entity. Reference: RFC 5213: Sections 2, 6.1
pmip6LmaMnLLIdentifier
1.3.6.1.2.1.206.1.3.2.5.1.1
Pmip6MnLLIdentifierAn identifier that identifies the attached interface of a mobile node.Reference: RFC 5213: Section 8.6 SIZE (0..255) · OCTET STRING · hint 255a
The link-layer identifier of the mobile node's connected interface on the access link.
A table representing the home network prefixes assigned to the connected interfaces of all the mobile nodes anchored at the LMA. Reference: RFC 5213: Sections 2, 5.1, 5.2
pmip6LmaHomeNetworkPrefixType
1.3.6.1.2.1.206.1.3.2.6.1.1
InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address.
unknown(0) An unknown address type. This value MUST
be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below.
ipv4(1) An IPv4 address as defined by the
InetAddressIPv4 textual convention.
ipv6(2) An IPv6 address as defined by the
InetAddressIPv6 textual convention.
ipv4z(3) A non-global IPv4 address including a zone
index as defined by the InetAddressIPv4z textual convention.
ipv6z(4) A non-global IPv6 address including a zone
index as defined by the InetAddressIPv6z textual convention.
dns(16) A DNS domain name as defined by the
InetAddressDNS textual convention.
Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType.
To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation.
Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32
The InetAddressType of the pmip6LmaHomeNetworkPrefix that follows.
pmip6LmaHomeNetworkPrefix
1.3.6.1.2.1.206.1.3.2.6.1.2
InetAddressDenotes a generic Internet address.
An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row.
The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error.
When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING
The mobile network prefix that is delegated to the mobile node. The type of the address represented by this object is specified by the corresponding pmip6LmaHomeNetworkPrefixType object. Reference: RFC 5213: Section 2
pmip6LmaHomeNetworkPrefixLength
1.3.6.1.2.1.206.1.3.2.6.1.3
InetAddressPrefixLengthDenotes the length of a generic Internet network address prefix. A value of n corresponds to an IP address mask that has n contiguous 1-bits from the most significant bit (MSB), with all other bits set to 0.
An InetAddressPrefixLength value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddressPrefixLength textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddressPrefixLength textual convention, if they appear in the same logical row.
InetAddressPrefixLength values larger than the maximum length of an IP address for a specific InetAddressType are treated as the maximum significant value applicable for the InetAddressType. The maximum significant value is 32 for the InetAddressType 'ipv4(1)' and 'ipv4z(3)' and 128 for the InetAddressType 'ipv6(2)' and 'ipv6z(4)'. The maximum significant value for the InetAddressType 'dns(16)' is 0.
The value zero is object-specific and must be defined as part of the description of any object that uses this syntax. Examples of the usage of zero might include situations where the Internet network address prefix is unknown or does not apply.
The upper bound of the prefix length has been chosen to be consistent with the maximum size of an InetAddress. (0..2040) · Unsigned32 · hint d
The prefix length of the home network prefix.
pmip6LmaHomeNetworkPrefixLifeTime
1.3.6.1.2.1.206.1.3.2.6.1.4
Gauge32 · seconds
The lifetime (in seconds) granted to the mobile node for this registration. Reference: RFC 5213: Section 5.3
Trap details
pmip6MagHomeTunnelEstablished
1.3.6.1.2.1.206.0.1
This notification is sent by the Proxy Mobile IPv6 entities every time the tunnel is established between the local mobility anchor and mobile access gateway. Reference: RFC 5213: Section 5.6.1
pmip6MagBLTunnelIfIdentifier
1.3.6.1.2.1.206.1.2.3.1.1.7
Ipv6AddressIfIdentifierTCThis data type is used to model IPv6 address interface identifiers. This is a binary string of up to 8 octets in network byte-order. SIZE (0..8) · OCTET STRING · hint 2x:
The tunnel interface identifier (tunnel-if-id) of the bidirectional tunnel between the mobile node's local mobility anchor and the mobile access gateway. This is internal to the mobile access gateway. The tunnel interface identifier is acquired during the tunnel creation. Reference: RFC 5213: Sections 6.1, 8.1
This object indicates the state of the Proxy-CoA:
unknown -- The state of the Proxy-CoA
cannot be determined.
activated -- The Proxy-CoA is ready to establish
a tunnel. This state SHOULD be indicated when the MAG is up but has no mobile node.
tunneled -- Bidirectional tunnel is established
using the Proxy-CoA.
pmip6MagHomeTunnelReleased
1.3.6.1.2.1.206.0.2
This notification is sent by the Proxy Mobile IPv6 entities every time the tunnel between the local mobility anchor and mobile access gateway is released. Reference: RFC 5213: Section 5.6.1
pmip6MagBLTunnelIfIdentifier
1.3.6.1.2.1.206.1.2.3.1.1.7
Ipv6AddressIfIdentifierTCThis data type is used to model IPv6 address interface identifiers. This is a binary string of up to 8 octets in network byte-order. SIZE (0..8) · OCTET STRING · hint 2x:
The tunnel interface identifier (tunnel-if-id) of the bidirectional tunnel between the mobile node's local mobility anchor and the mobile access gateway. This is internal to the mobile access gateway. The tunnel interface identifier is acquired during the tunnel creation. Reference: RFC 5213: Sections 6.1, 8.1
This object indicates the state of the Proxy-CoA:
unknown -- The state of the Proxy-CoA
cannot be determined.
activated -- The Proxy-CoA is ready to establish
a tunnel. This state SHOULD be indicated when the MAG is up but has no mobile node.
tunneled -- Bidirectional tunnel is established
using the Proxy-CoA.
pmip6LmaHomeTunnelEstablished
1.3.6.1.2.1.206.0.3
This notification is sent by the Proxy Mobile IPv6 entities every time the tunnel is established between the local mobility anchor and mobile access gateway. Reference: RFC 5213: Section 5.6.1
pmip6BindingTunnelIfIdentifier
1.3.6.1.2.1.206.1.1.2.1.1.6
Ipv6AddressIfIdentifierTCThis data type is used to model IPv6 address interface identifiers. This is a binary string of up to 8 octets in network byte-order. SIZE (0..8) · OCTET STRING · hint 2x:
The tunnel interface identifier (tunnel-if-id) of the bidirectional tunnel between the local mobility anchor and the mobile access gateway where the mobile node is currently anchored. This is internal to the local mobility anchor. The tunnel interface identifier is acquired during the tunnel creation. Reference: RFC 5213: Sections 5.1, 8.1
This object indicates the state of the LMAA:
unknown -- The state of the LMAA
cannot be determined.
activated -- The LMAA is ready to establish
a tunnel.
tunneled -- The LMAA is used to set up the
bidirectional tunnel.
pmip6LmaHomeTunnelReleased
1.3.6.1.2.1.206.0.4
This notification is sent by the Proxy Mobile IPv6 entities every time the tunnel between the local mobility anchor and mobile access gateway is released. Reference: RFC 5213: Section 5.6.1
pmip6BindingTunnelIfIdentifier
1.3.6.1.2.1.206.1.1.2.1.1.6
Ipv6AddressIfIdentifierTCThis data type is used to model IPv6 address interface identifiers. This is a binary string of up to 8 octets in network byte-order. SIZE (0..8) · OCTET STRING · hint 2x:
The tunnel interface identifier (tunnel-if-id) of the bidirectional tunnel between the local mobility anchor and the mobile access gateway where the mobile node is currently anchored. This is internal to the local mobility anchor. The tunnel interface identifier is acquired during the tunnel creation. Reference: RFC 5213: Sections 5.1, 8.1
This object indicates the state of the LMAA:
unknown -- The state of the LMAA
cannot be determined.
activated -- The LMAA is ready to establish
a tunnel.
tunneled -- The LMAA is used to set up the
bidirectional tunnel.