Definitions of Managed Objects for ATM Management
RFC 2515
| Document | Type |
RFC
- Proposed Standard
(February 1999)
Obsoletes RFC 1695
|
|
|---|---|---|---|
| Author | Kaj Tesink | ||
| Last updated | 2013-03-02 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | (None) | |
| Send notices to | (None) |
RFC 2515
Network Working Group C. Allocchio
Request for Comments: 1405 I.N.F.N. - Italy
January 1993
Mapping between X.400(1984/1988) and Mail-11 (DECnet mail)
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. Discussion and suggestions for improvement are requested.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
Abstract
This document describes a set of mappings which will enable inter
working between systems operating the CCITT X.400 ( 1984 / 1988 )
Recommendations on Message Handling Systems, and systems running the
Mail-11 (also known as DECnet mail) protocol. The specifications are
valid within DECnet Phase IV addressing and routing scheme.
The complete scenario of X.400 / RFC822 / Mail-11 is also considered,
in order to cover the possible complex cases arising in multiple
gateway translations.
This document covers mainly the O/R address to DECnet from/to address
mapping (and vice versa); other mappings are based on RFC 1327 and
its eventual future updates.
This is a combined effort of COSINE S2.2, the RARE MSG Working Group,
and the IETF X.400 Ops Working Group.
Chapter 1 - Introduction
1.1. X.400
The standard referred shortly into this document as "X.400" relates
to the CCITT 1984 and 1988 X.400 Series Recommendations covering the
Message Oriented Text Interchange Service (MOTIS). This document
covers the Inter Personal Messaging System (IPMS) only.
1.2. Mail-11
Mail-11, also known as DECnet mail and often improperly referred as
VMSmail, is the proprietary protocol implemented by Digital Equipment
Corporation (DEC) to establish a real-time text messaging system
Allocchio [Page 1]
RFC 1405 Mail-11 Mapping January 1993
among systems implementing the DECnet Phase IV networking protocols.
1.3. RFC822
RFC822 was defined as a standard for personal messaging systems
within the DARPA Internet and is now diffused on top of many
different message transfer protocols, like SMTP, UUCP, BITNET, JNT
Grey Book, CSnet. Its mapping with X.400 is fully described in
RFC1327. In this document we will try to consider its relations with
Mail-11, too.
1.4. The user community
The community using X.400 messaging system is currently growing in
the whole world, but there is still a number of very large
communities using Mail-11 based messaging systems willing to
communicate easily with X.400 based Message Handling Systems. Among
these large DECnet based networks we can include the High Energy
Physics network (HEPnet) and the Space Physics Analysis Network
(SPAN).
These DECnet communities will in the future possibly migrate to
DECnet Phase V (DECnet-OSI) protocols, converting thus their
messaging systems to OSI specifications, i.e., merging into the X.400
MHS; however the transition period could be long, and there could
always be some DECnet Phase IV communities around.
For these reasons a set of mapping rules covering conversion between
Mail-11 and X.400 is described in this document.
This document also covers the case of Mail-11 systems implementing
the "foreign mail protocol" allowing Mail-11 to interface other mail
systems, including RFC822 based system.
Chapter 2 - Message Elements
2.1. Service Elements
Mail-11 protocol offers a very restricted set of elements composing a
Inter Personal Message (IPM), whereas X.400 specifications support a
complex and large amount of service elements. Considering the case
where a message is relayed between two X.400 MHS via a DECnet network
this could result in a nearly complete loss of information. To
minimise this inconvenience most of X.400 service elements will be
mapped into Mail-11 text body parts. To consider also the case when a
message originates from a network implementing RFC822 protocols and
is relayed via Mail-11 to and X.400 MHS, the applied mapping from
X.400 service elements into Mail-11 text body part the rules
Allocchio [Page 2]
RFC 1405 Mail-11 Mapping January 1993
specified in RFC1327 and their updates will be used, producing an
RFC822-like header.
2.2. Mail-11 service elements
All envelope (P1) and header (P2) Mail-11 service elements are
supported in the conversion to X.400. Note that Mail-11 P1 is solely
composed by P1.From and P1.To, and any other Mail-11 element belongs
to Mail-11 P2:
- P1.From
maps to P1.Originator
- P1.To
maps to P1.Primary Recipient
- P2.From
maps to P2.Originator
- P2.To
maps to P2.Primary Recipient
- Cc
maps to P2.Copy Recipient
- Date
maps to Submission Time Stamp
- Subj
maps to Subject
Any eventual RFC822-like text header in Mail-11 body part will be
interpreted as specified into RFC1327 and its updates.
2.3. X.400 service elements
The following X.400 service elements are supported directly into
Mail-11 conversion:
- P1.Originator
maps to P1.'From'
- P1.Primary Recipients
maps to P1.'To'
- P2.Originator
maps to P2.'From'
Allocchio [Page 3]
RFC 1405 Mail-11 Mapping January 1993
- P2.Primary Recipients
maps to P2.'To'
- Copy Recipients
maps to 'Cc'
- Submission Time Stamp
maps to 'date'
- Subject
maps to 'Subj'
The following X.400 service element is partially supported into
Mail-11 conversion:
- Blind Copy Recipient
to ensure the required privacy, when a message contains
a BCC address, the following actions occurs:
- a new message is created, containing the body parts;
- a new envelope is added to the new message, containing
the originator and the BCC recipient addresses only;
- a note is added to the message informing the BCC
recipient about the fact that the message was a BCC;
- the new message is delivered separately;
- a note is added to the message delivered to TO and CC
recipients informing them about the fact that there
were some BCC recipients, too.
Any other X.400 service element support is done accordingly to
RFC1327 including the mapped element into the RFC822-like header into
Mail-11 body part.
Chapter 3 - Basic Mappings
The basic mappings indicated in RFC1327 and its updates should be
fully used.
Chapter 4 - Addressing
4.1. Mail-11 addressing
Mail-11 addressing can vary from a very simple case up to complex
ones, if there are other Mail-11 to "something-else" gateways
involved. In any case a Mail-11 address is an ASCII string composed
of different elements.
Allocchio [Page 4]
quot;
OBJECT atmVcCrossConnectAdminStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVcCrossConnectRowStatus
SYNTAX INTEGER { active(1)}
-- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one
of the six enumerated values for the
RowStatus textual convention need be
supported, specifically: active(1)."
--
-- ****** AAL5 Support ******************************
--
GROUP aal5VccGroup
Tesink Standards Track [Page 71]
RFC 2515 ATM Management Objects February 1999
DESCRIPTION
"This group is mandatory for the
AAL5 virtual connections only."
OBJECT atmVccAal5CpcsTransmitSduSize
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVccAal5CpcsReceiveSduSize
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVccAal5EncapsType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { atmMIBCompliances 2 }
-- Units of Conformance
atmInterfaceDs3PlcpGroup OBJECT-GROUP
OBJECTS {atmInterfaceDs3PlcpSEFSs,
atmInterfaceDs3PlcpAlarmState,
atmInterfaceDs3PlcpUASs}
STATUS current
DESCRIPTION
"A collection of objects providing information
about DS3 PLCP layer at an ATM interface."
::= { atmMIBGroups 3 }
atmInterfaceTCGroup OBJECT-GROUP
OBJECTS { atmInterfaceOCDEvents,
atmInterfaceTCAlarmState }
STATUS current
DESCRIPTION
"A collection of objects providing information
about TC sublayer at an ATM interface."
::= { atmMIBGroups 4 }
aal5VccGroup OBJECT-GROUP
OBJECTS {atmVccAal5CpcsTransmitSduSize,
atmVccAal5CpcsReceiveSduSize,
atmVccAal5EncapsType,
aal5VccCrcErrors, aal5VccSarTimeOuts,
aal5VccOverSizedSDUs }
STATUS current
Tesink Standards Track [Page 72]
RFC 2515 ATM Management Objects February 1999
DESCRIPTION
"A collection of objects providing
AAL5 configuration and performance statistics
of a VCC."
::= { atmMIBGroups 9 }
atmInterfaceConfGroup2 OBJECT-GROUP
OBJECTS {
atmInterfaceMaxVpcs, atmInterfaceMaxVccs,
atmInterfaceConfVpcs, atmInterfaceConfVccs,
atmInterfaceMaxActiveVpiBits,
atmInterfaceMaxActiveVciBits,
atmInterfaceIlmiVpi,
atmInterfaceIlmiVci,
atmInterfaceMyNeighborIpAddress,
atmInterfaceMyNeighborIfName,
atmInterfaceCurrentMaxVpiBits,
atmInterfaceCurrentMaxVciBits,
atmInterfaceSubscrAddress }
STATUS current
DESCRIPTION
"A collection of objects providing configuration
information about an ATM interface."
::= { atmMIBGroups 10 }
atmTrafficDescrGroup2 OBJECT-GROUP
OBJECTS {
atmTrafficDescrType, atmTrafficDescrParam1,
atmTrafficDescrParam2, atmTrafficDescrParam3,
atmTrafficDescrParam4, atmTrafficDescrParam5,
atmTrafficDescrRowStatus, atmServiceCategory,
atmTrafficFrameDiscard,
atmTrafficDescrParamIndexNext }
STATUS current
DESCRIPTION
"A collection of objects providing information
about ATM traffic descriptor type and
the associated parameters."
::= { atmMIBGroups 11 }
atmVpcTerminationGroup2 OBJECT-GROUP
OBJECTS {atmVplOperStatus, atmVplAdminStatus,
atmVplLastChange,
atmVplReceiveTrafficDescrIndex,
atmVplTransmitTrafficDescrIndex,
atmVplRowStatus, atmVplCastType,
atmVplConnKind }
STATUS current
Tesink Standards Track [Page 73]
RFC 2515 ATM Management Objects February 1999
DESCRIPTION
"A collection of objects providing information
about a VPL at an ATM interface which
terminates a VPC (i.e., one which is NOT
cross-connected to other VPLs)."
::= { atmMIBGroups 12 }
atmVccTerminationGroup2 OBJECT-GROUP
OBJECTS {atmVclOperStatus, atmVclAdminStatus,
atmVclLastChange,
atmVclReceiveTrafficDescrIndex,
atmVclTransmitTrafficDescrIndex,
atmVccAalType, atmVclRowStatus,
atmVclCastType, atmVclConnKind }
STATUS current
DESCRIPTION
"A collection of objects providing information
about a VCL at an ATM interface
which terminates a VCC (i.e., one which is
NOT cross-connected to other VCLs)."
::= { atmMIBGroups 13 }
atmVplCrossConnectGroup OBJECT-GROUP
OBJECTS { atmVplReceiveTrafficDescrIndex,
atmVplTransmitTrafficDescrIndex,
atmVplOperStatus, atmVplLastChange,
atmVplRowStatus,
atmVplCastType, atmVplConnKind }
STATUS current
DESCRIPTION
"A collection of objects providing
information about the VPLs that
are cross-connected together."
::= { atmMIBGroups 14 }
atmVpPvcCrossConnectGroup OBJECT-GROUP
OBJECTS { atmVpCrossConnectAdminStatus,
atmVpCrossConnectL2HOperStatus,
atmVpCrossConnectH2LOperStatus,
atmVpCrossConnectL2HLastChange,
atmVpCrossConnectH2LLastChange,
atmVpCrossConnectRowStatus,
atmVplCrossConnectIdentifier,
atmVpCrossConnectIndexNext }
STATUS current
DESCRIPTION
"A collection of objects providing
information about a VP cross-connect
Tesink Standards Track [Page 74]
RFC 2515 ATM Management Objects February 1999
for PVCs. These objects are not used
for Soft PVCs or SVCs."
::= { atmMIBGroups 15 }
atmVclCrossConnectGroup OBJECT-GROUP
OBJECTS { atmVclReceiveTrafficDescrIndex,
atmVclTransmitTrafficDescrIndex,
atmVclOperStatus, atmVclLastChange,
atmVclRowStatus,
atmVclCastType, atmVclConnKind }
STATUS current
DESCRIPTION
"A collection of objects providing
information about the VCLs that
are cross-connected together."
::= { atmMIBGroups 16 }
atmVcPvcCrossConnectGroup OBJECT-GROUP
OBJECTS { atmVcCrossConnectAdminStatus,
atmVcCrossConnectL2HOperStatus,
atmVcCrossConnectH2LOperStatus,
atmVcCrossConnectL2HLastChange,
atmVcCrossConnectH2LLastChange,
atmVcCrossConnectRowStatus,
atmVclCrossConnectIdentifier,
atmVcCrossConnectIndexNext }
STATUS current
DESCRIPTION
"A collection of objects providing
information about a VC cross-connect
for PVCs. These objects are not used
for Soft PVCs or SVCs."
::= { atmMIBGroups 17 }
-- Deprecated Definitions - Objects
-- atmInterfaceAddressType
-- atmTrafficQoSClass
-- Deprecated Definitions - Compliance
atmMIBCompliance MODULE-COMPLIANCE
STATUS deprecated
DESCRIPTION
"The compliance statement for SNMP entities
including networks which have ATM and
Tesink Standards Track [Page 75]
RFC 2515 ATM Management Objects February 1999
AAL5 interfaces."
MODULE -- this module
MANDATORY-GROUPS {atmInterfaceConfGroup,
atmTrafficDescrGroup}
OBJECT atmInterfaceMaxVpcs
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmInterfaceMaxVccs
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmInterfaceMaxActiveVpiBits
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmInterfaceMaxActiveVciBits
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmInterfaceIlmiVpi
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmInterfaceIlmiVci
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmInterfaceMyNeighborIpAddress
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmInterfaceMyNeighborIfName
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmTrafficDescrType
MIN-ACCESS read-only
Tesink Standards Track [Page 76]
RFC 2515 ATM Management Objects February 1999
DESCRIPTION
"Write access is not required."
OBJECT atmTrafficDescrParam1
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmTrafficDescrParam2
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmTrafficDescrParam3
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmTrafficDescrParam4
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmTrafficDescrParam5
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmTrafficQoSClass
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmTrafficDescrRowStatus
SYNTAX INTEGER {active(1)}
-- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one
of the six enumerated values for the
RowStatus textual convention need be
supported, specifically: active(1)."
GROUP atmInterfaceDs3PlcpGroup
DESCRIPTION
"This group is mandatory only for those
ATM interfaces which implement the
DS3 PLCP layer."
Tesink Standards Track [Page 77]
RFC 2515 ATM Management Objects February 1999
GROUP atmInterfaceTCGroup
DESCRIPTION
"This group is mandatory only for those
ATM interfaces which implement the
TC Sublayer."
GROUP atmVpcTerminationGroup
DESCRIPTION
"This group is mandatory only for those
ATM interfaces which implement ATM
VPLs that terminate VPCs (i.e., ones which
are NOT cross-connected to other VPLs)."
GROUP atmVpCrossConnectGroup
DESCRIPTION
"This group is mandatory only for those
ATM interfaces which implement ATM
VPLs that are not associated with VCLs
and are cross-connected to other VPLs."
OBJECT atmVplAdminStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVplReceiveTrafficDescrIndex
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVplTransmitTrafficDescrIndex
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVplRowStatus
SYNTAX INTEGER {active(1)}
-- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
RFC 1405 Mail-11 Mapping January 1993
4.2. X.400 addressing
On the other hand, An X.400 O/R address is a collection of
attributes, which can anyway be presented as an IA5 textual
representation as defined in chapter 4 of RFC1327.
4.3. Mail-11 address components
Let us start defining the different parts composing a Mail-11
address. We can consider any Mail-11 address as composed by 3 parts:
[[route]::] [[node]::] local-part
where 'route' and 'node' are optional and only 'local-part' is
compulsory.
Here comes a strict definition of these elements
node = *(ALPHA/DIGIT) / *DIGIT / *DIGIT "." *DIGIT
route = *(node "::")
local-part = username / nickname / for-protocol
username = *(ALPHA/DIGIT)
nickname = <printablestring - <" " and HTAB>>
for-protocol = (f-pref f-sep <">f-address<">)
f-pref = *(ALPHA/DIGIT)
f-sep = "%" / "::"
f-address = printablestring / RFC822-address / X400-text-address
X400-text-address = <textual representation of an X.400 O/R addr>
Please note that in x-text-address both the ";" notation and the "/"
notation are equivalent and allowed (see examples in different sect.)
Allocchio [Page 5]
RFC 1405 Mail-11 Mapping January 1993
Some examples:
route node local-part
-----------------------------------------------------------
USER47
MYNODE::BETTY
BOSTON::CLUS02::GOOFY1::MARY34
IN%"M.P.Tracy@Dicdum.cc.edu"
UCLA13::MVAX93::MRGATE::"MBOX1::MBX34::MYC3::BOB"
MIAMI2::George.Rosenthal
CCUBVX::VS3100::Jnet%"IAB3425@IBAX23L"
MRGATE::"C=xx::A=bbb::P=ppp::S=Joe"
MAINVX::IN%"path1!path2!user%dom"
GWX400::gw%"C=xx;ADMD=aaa;PRMD=ppp;S=Lee;"
GX409A::x400%"/C=xx/A=aaa/P=ppp/S=Lee"
smtp%"postmast@nodeb.bitnet"
MICKEY::PRFGAT::profs%"NANCY@IBMB"
edu%"HU427BD%CSUNIB@abc.acme.edu"
Chapter 5 - Mapping
5.1. Mapping scheme
DECnet address field is somehow a 'flat land' with some obliged
routes to reach some hidden areas. Thus a truly hierarchical mapping
scheme using mapping tables as suitable for RFC822 is not the
appropriate solution. A fixed set of rules using DDAs support is
defined in order to define the mapping.
Another important aspect of the problem is the coexistence of many
disjoint DECnet networks, using the same DECnet address space, i.e.,
common X.400 and/or RFC822 mailing system acting as glue to connect
different isolated Mail-11 islands. Thus, to identify uniquely each
DECnet network we must also introduce the concept of 'DECnet network
name', which we will refer shortly as 'net' from now onwards. We
define as 'net' a unique ASCII string identifying the DECnet network
we are connected to. To be more specific, the 'net' element will
identify the DECnet community being served, i.e., it could also
differ from the actual official network name. Aliases are allowed for
the
net = 'HEPnet' the High Energy Physics DECnet network
net = 'SPAN' the Space Physics Analysis Network
net = 'Enet' the Digital Equipment Corporate Network
The need of labelling each DECnet network with its name comes also
from the requirement to implement the 'intelligent' gateway, i.e.,
the gateway which is able to understand its ability to connect
Allocchio [Page 6]
RFC 1405 Mail-11 Mapping January 1993
directly to the specified DECnet network, even if the O/R address
specify a path to a different gateway. A more detailed discussion of
the problem is in 5.3 and 5.5.
A registry of 'net' attributes and their correspondent gateways must
also be implemented to insure uniqueness of names. A simple table
coupling 'net' and the gateway address is used, in a syntax similar
to the 'gate' table used in RFC1327. An example:
HEPnet#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT#
SPAN#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT#
SPAN#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it#
Ambiguous left entries are allowed. Gateway implementations could
simply choose among one of them, or try them all in cyclic order to
obtain better performances.
In order to keep the mapping rules very simple, avoiding the need to
analyse Mail-11 addresses to distinguish the 'route', 'node' and
needed to cover the mapping problem.
5.2. Mail-11 --> X.400
We define the following Domain Defined Attributes to map a Mail-11
address:
DD.Dnet
DD.Mail-11
We thus define the mapping rule
route::node::localpart
maps into
C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net;
DD.Mail-11=route::node::localpart;
with
xx = country code of the gateway performing the conversion
yyy = Admd of the gateway performing the conversion
zzz = Prmd of the gateway performing the conversion
ooo = Organisation of the gateway performing the conversion
uuu = Org. Unit(s) of the gateway performing the conversion
net = name of the DECnet network (e.g., HEPnet, SPAN,...)
('zzz','ooo','uuu' being used or dropped appropriately in order to
Allocchio [Page 7]
RFC 1405 Mail-11 Mapping January 1993
identify uniquely within the X.400 MHS the gateway performing the
conversion).
The following defaults also apply:
if 'node' is missing and we are mapping the Mail-11 originator (From)
then 'node' defaults to the DECnet node name of the gateway (gwnode);
if 'node' is missing and we are mapping the Mail-11 recipient (To,
Cc) then 'node' defaults to the DECnet node name of the 'From'
address.
if 'DD.Dnet=net' is missing, then it defaults to a value defined
locally by the gateway: if the gateway is connected to one DECnet
network only, then 'net' will be the name of this unique network; if
the gateway is connected to more than one DECnet network, then the
gateway will establish a 'first choice' DECnet network, and 'net'
will default to this value.
In case 'local-part' contains 'x400-text-address' see also section
6.4.3;
In case 'local-part' contains 'RFC822-address' see also section
6.4.4.
5.2.1. Examples
Let us suppose that:
the DECnet network name (net) is 'HEP';
the DECnet node name of the gateway (gwnode) is 'X4TDEC';
the Country Code of the gateway is 'IT' and its ADMD is 'garr'
(and these two fields are enough to identify uniquely the gateway
within the X.400 MHS).
USER47
C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=X4TDEC::USER47;
MYNODE::BETTY
C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=MYNODE::BETTY;
BOSTON::CLUS02::GOOFY1::MARY34
C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=BOSTON::GOOFY1::MARY34;
UCLA13::MVAX93::MRGATE::"MBOX1::MBX34:MYC3::BOB"
C=it; ADMD=garr; DD.Dnet=HEP;
DD.Mail-11=UCLA13::MVAX93::MRGATE::(q)MBOX1::MBX34::MYC3::BOB(q)
Allocchio [Page 8]
RFC 1405 Mail-11 Mapping January 1993
MIAMI2::George.Rosenthal
C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=MIAMI2::George.Rosenthal;
MRGATE::"C=xx::A=bbb::P=ppp::S=Joe"
C=it; ADMD=garr; DD.Dnet=HEP;
DD.Mail-11=X4TDEC::MRGATE::(q)C=xx::A=bbb::P=ppp::S=Joe(q)
MAINVX::In%"path1!path2!user%dom"
C=it; ADMD=garr; DD.Dnet=HEP;
DD.Mail-11=MAINVX::In(p)(q)path1(b)path2(b)user(p)dom(q)
5.3. X.400 encoding of Mail-11 --> Mail-11
In order to assure path reversibility in case of multiple Mail-
11/X.400 gateway crossing we must distinguish two cases:
- DD.Dnet=net is known to the gateway as one of the DECnet networks
it is connected to. In this case the mapping is trivial:
C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net;
DD.Mail-11=route::node::localpart;
(see sect. 5.2 for explication of 'xx','yyy','zzz','ooo"Write access is not required, and only one
of the six enumerated values for the
RowStatus textual convention need be
supported, specifically: active(1)."
OBJECT atmVpCrossConnectAdminStatus
MIN-ACCESS read-only
DESCRIPTION
Tesink Standards Track [Page 78]
RFC 2515 ATM Management Objects February 1999
"Write access is not required."
OBJECT atmVpCrossConnectRowStatus
SYNTAX INTEGER {active(1)}
-- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one
of the six enumerated values for the
RowStatus textual convention need be
supported, specifically: active(1)."
GROUP atmVccTerminationGroup
DESCRIPTION
"This group is mandatory only for those
ATM interfaces which implement ATM
VCLs that terminate VCCs (i.e., ones which
are NOT cross-connected to other VCLs)."
GROUP atmVcCrossConnectGroup
DESCRIPTION
"This group is mandatory only for those
ATM interfaces which implement ATM
VCLs that are cross-connected to
other VCLs."
OBJECT atmVclAdminStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVclReceiveTrafficDescrIndex
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVclTransmitTrafficDescrIndex
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVccAalType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVclRowStatus
SYNTAX INTEGER {active(1)}
Tesink Standards Track [Page 79]
RFC 2515 ATM Management Objects February 1999
-- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one
of the six enumerated values for the
RowStatus textual convention need be
supported, specifically: active(1)."
OBJECT atmVcCrossConnectAdminStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVcCrossConnectRowStatus
SYNTAX INTEGER { active(1)}
-- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one
of the six enumerated values for the
RowStatus textual convention need be
supported, specifically: active(1)."
GROUP aal5VccGroup
DESCRIPTION
"This group is mandatory for the
AAL5 virtual connections only."
OBJECT atmVccAal5CpcsTransmitSduSize
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVccAal5CpcsReceiveSduSize
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVccAal5EncapsType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { atmMIBCompliances 1 }
-- Deprecated Definitions - Groups
Tesink Standards Track [Page 80]
RFC 2515 ATM Management Objects February 1999
atmInterfaceConfGroup OBJECT-GROUP
OBJECTS {
atmInterfaceMaxVpcs, atmInterfaceMaxVccs,
atmInterfaceConfVpcs, atmInterfaceConfVccs,
atmInterfaceMaxActiveVpiBits,
atmInterfaceMaxActiveVciBits,
atmInterfaceIlmiVpi,
atmInterfaceIlmiVci,
atmInterfaceAddressType,
atmInterfaceAdminAddress,
atmInterfaceMyNeighborIpAddress,
atmInterfaceMyNeighborIfName }
STATUS deprecated
DESCRIPTION
"A collection of objects providing configuration
information about an ATM interface."
::= { atmMIBGroups 1 }
atmTrafficDescrGroup OBJECT-GROUP
OBJECTS {
atmTrafficDescrType, atmTrafficDescrParam1,
atmTrafficDescrParam2, atmTrafficDescrParam3,
atmTrafficDescrParam4, atmTrafficDescrParam5,
atmTrafficQoSClass, atmTrafficDescrRowStatus}
STATUS deprecated
DESCRIPTION
"A collection of objects providing information
about ATM traffic descriptor type and
the associated parameters."
::= { atmMIBGroups 2 }
atmVpcTerminationGroup OBJECT-GROUP
OBJECTS {atmVplOperStatus, atmVplAdminStatus,
atmVplLastChange,
atmVplReceiveTrafficDescrIndex,
atmVplTransmitTrafficDescrIndex,
atmVplRowStatus }
STATUS deprecated
DESCRIPTION
"A collection of objects providing
information about a VPL at an ATM interface
which terminates a VPC
(i.e., one which is NOT cross-connected
to other VPLs)."
::= { atmMIBGroups 5 }
atmVccTerminationGroup OBJECT-GROUP
OBJECTS {atmVclOperStatus, atmVclAdminStatus,
Tesink Standards Track [Page 81]
RFC 2515 ATM Management Objects February 1999
atmVclLastChange,
atmVclReceiveTrafficDescrIndex,
atmVclTransmitTrafficDescrIndex,
atmVccAalType, atmVclRowStatus }
STATUS deprecated
DESCRIPTION
"A collection of objects providing information
about a VCL at an ATM interface
which terminates a VCC (i.e., one which is
NOT cross-connected to other VCLs)."
::= { atmMIBGroups 6 }
atmVpCrossConnectGroup OBJECT-GROUP
OBJECTS { atmVplReceiveTrafficDescrIndex,
atmVplTransmitTrafficDescrIndex,
atmVplOperStatus, atmVplRowStatus,
atmVpCrossConnectAdminStatus,
atmVpCrossConnectL2HOperStatus,
atmVpCrossConnectH2LOperStatus,
atmVpCrossConnectL2HLastChange,
atmVpCrossConnectH2LLastChange,
atmVpCrossConnectRowStatus,
atmVplCrossConnectIdentifier,
atmVpCrossConnectIndexNext }
STATUS deprecated
DESCRIPTION
"A collection of objects providing
information about a VP cross-connect
and the associated VPLs that are
cross-connected together."
::= { atmMIBGroups 7 }
atmVcCrossConnectGroup OBJECT-GROUP
OBJECTS { atmVclReceiveTrafficDescrIndex,
atmVclTransmitTrafficDescrIndex,
atmVclOperStatus, atmVclRowStatus,
atmVcCrossConnectAdminStatus,
atmVcCrossConnectL2HOperStatus,
atmVcCrossConnectH2LOperStatus,
atmVcCrossConnectL2HLastChange,
atmVcCrossConnectH2LLastChange,
atmVcCrossConnectRowStatus,
atmVclCrossConnectIdentifier,
atmVcCrossConnectIndexNext }
STATUS deprecated
DESCRIPTION
"A collection of objects providing
information about a VC cross-connect
Tesink Standards Track [Page 82]
RFC 2515 ATM Management Objects February 1999
and the associated VCLs that are
cross-connected together."
::= { atmMIBGroups 8 }
-- {atmMIB 3} has been used by [19].
END
10. Acknowledgments
This memo is the result of the work of the AToMMIB Working Group.
11. References
[1] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for Describing SNMP Management Frameworks", RFC
2271, January 1998.
[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] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Structure of Management Information for Version 2
of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
January 1996.
[6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Textual Conventions for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
[7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Conformance Statements for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
[8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, May 1990.
[9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901,
January 1996.
Tesink Standards Track [Page 83]
RFC 2515 ATM Management Objects February 1999
[10] SNMPv2 Working Group, 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 2272, January 1998.
[12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
for version 3 of the Simple Network Management Protocol
(SNMPv3)", RFC 2274, January 1998.
[13] SNMPv2 Working Group, 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, MPv3 Applications", RFC
2273, January 1998.
[15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", RFC 2275, January 1998.
[16] McCloghrie, K. and M. Rose, Editors, "Management Information
Base for Network Management of TCP/IP-based internets: MIB-II",
STD 17, RFC 1213, March 1991.
[17] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
RFC 2233, November 1997.
[18] Brown, T. and K. Tesink, "Definitions of Managed Objects for
SMDS Interfaces", RFC 1694, May 1994.
[19] Noto, M., Spiegel, E. and K. Tesink, Editors, "Definitions of
Textual Conventions and OBJECT-IDENTITIES for ATM Management",
RFC 2514, February 1999.
[20] ATM Forum, ATM User-Network Interface, Version 3.0 (UNI 3.0)
Specification, 1994.
[21] ATM Forum, B-ICI Specification, Version 2.0, af-bici-0013.002,
November 1995.
[22] "ATM Forum Private Network-Network Interface Specification,
Version 1.0 (PNNI 1.0)", af-sig-0055.000, March 1996.
[23] "ATM Forum Integrated Local Management Interface (ILMI)
Specification", Version 4.0", af-ilmi-0065.000, September 1996.
Tesink Standards Track [Page 84]
RFC 2515 ATM Management Objects February 1999
[24] Ahmed, M. and K. Tesink, "Definitions of Managed Objects for ATM
Management Version 8.0 using SMIv2", RFC 1695, August 1994.
12. Security Considerations
There are a number of management objects defined in this MIB that
have a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations.
The managed objects in this MIB contain sensitive information since,
collectively, they allow tracing and influencing of virtual
connections in ATM switches or networks and provide information of
their traffic characteristics.
It is thus important to control even GET access to these objects and
possibly to even encrypt the values of these object when sending them
over the network via SNMP. Not all versions of SNMP provide features
for such a secure environment.
SNMPv1 by itself is not a secure environment. Even if the network
itself is secure (for example by using IPSec), even then, there is no
control as to who on the secure network is allowed to access and
GET/SET (read/change/create/delete) the objects in this MIB.
It is recommended that the implementers consider the security
features as provided by the SNMPv3 framework. Specifically, the use
of the User-based Security Model RFC 2274 [12] and the View-based
Access Control Model RFC 2275 [15] is recommended.
It is then a customer/user responsibility to ensure that the SNMP
entity giving access to an instance of this MIB, is properly
configured to give access to the objects only to those principals
(users) that have legitimate rights to indeed GET or SET
(change/create/delete) them.
13. Author's Address
Kaj Tesink
Bellcore
331 Newman Springs Road
P.O. Box 7020
Red Bank, NJ 07701-7020
Phone: (732) 758-5254
EMail: kaj@bellcore.com
Tesink Standards Track [Page 85]
RFC 2515 ATM Management Objects February 1999
14. 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.
Tesink Standards Track [Page 86]
RFC 2515 ATM Management Objects February 1999
15. Full Copyright Statement
Copyright (C) The Internet Society (1999). 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.
Tesink Standards Track [Page 87]