1. EAGLE ENUM User's Guide
  2. Feature Description

2 Feature Description

This chapter describes the ENUM Mobile Number Portability and Tier One Address Resolution feature.

Introduction

The ENUM Mobile Number Portability and Tier One Address Resolution (ENUM) feature of the Oracle Communications EAGLE enhances the ability of EAGLE to access the Number Portability database (RxDB) using ENUM protocol. Using the ENUM interface supported on UDP, EAGLE is able to process a destination number lookup in an IP-based addressing scheme in the Number Portability database and provide a routing solution to the originating carrier.

ENUM Architecture

Figure 2-1 shows the overall system architecture for the ENUM feature on the EAGLE.

  • The ENUM application runs on the E5-SM8G-B or SLIC card loaded with the ENUM64 GPL.
  • The ENUM application communicates with OAMHC on EAGLE using the IMT bus.
  • The ENUM card connects to the EPAP using Ethernet Port A.
  • The ENUM card connects to the ENUM clients (switches or CSCF) using Ethernet Port B.

Figure 2-1 ENUM Architecture on EAGLE

img/enum_architecture_on_eagle.png

E.164 Number Mapping (ENUM)

E.164 Number Mapping (ENUM) is a Telephone Number Mapping standard defined for mapping of traditional PSTN numbers in E.164 format to IP-based format such as URI. ENUM uses a special DNS record type to translate a telephone number into a URI that can be used in an IP network. ENUM allows Internet-based services, such as E-mail, VoIP, and Voice Mail to be located based on the telephone number. ENUM accomplishes this by placing the telephone numbers into the global Domain Name System (DNS).

An ENUM Tier resolution from a DNS perspective example is shown in Figure 2-2. The ENUM data format begins with a phone number, then reverses the digits, places a “.” between each number, and adds an .e164.arpa root domain that is common across both ENUM and this feature.

Figure 2-2 ENUM Tier Record Resolution

img/enum_tier_record_resolution.png

ENUM implementation is based on a tiered architecture. At Tier 0 is the RIPE NCC which maintains the e164.arpa zone. Entries in the RIPE NCC DNS server correspond to country codes or portions of country codes and point to the Tier 1 Registry that is the authoritative DNS server for that country code or portion of country code. The Tier 1 Registry maintains records that indicate the authoritative DNS server for individual E.164 numbers in the country code or portion thereof. The Tier 2 Provider for an E.164 number maintains the actual NAPTR records that contain information for specific communication services.

Redundancy/Failover

Redundancy is divided into the Signaling Network redundancy and the Private Network redundancy on E5-SM8G-B or SLIC cards. Figure 2-3 shows the network redundancy for E5-SM8G-B cards on EAGLE.

Figure 2-3 Network Redundancy with E5-SM8G-B Cards

img/enum_network_redundancy_enum_cards.png

E5-SM8G-B Signaling Network

EAGLE supports up to 16 ENUM cards. Each ENUM card has its own IP address and operates independently. EAGLE does not provide load balancing between multiple ENUM cards. Users can implement load balancing on the client side or use a third-party load balancer between the client and the ENUM server on EAGLE which tracks connection status of each ENUM card. The ENUM client or load balancer must implement a failover mechanism in the event of connection failure and ENUM application card failure.

An ENUM card discards incoming messages from the ENUM client and pegs measurements for discarded ENUM queries in these two scenarios:

  • Inbound connection congestion on the ENUM card - Socket queue or Application Receive queue becoming full
  • Connection failure - ENUM messages on Receive and Transmit queues discarded

E5-SM8G-B Private Network

An ENUM card connects to the EPAP on a private network using Ethernet Port A. The RxDB data is downloaded to the ENUM card in same manner as Service Module cards are loaded.

However EPAP connectivity to an ENUM card and a Service Module card are different in the event of failure of Switch A. If Switch A (between EPAP A and EAGLE) or Port A on the EAGLE Service Module card fails, the Service Module card starts data download using Switch B or Port B. For the ENUM card, the connecting cable must be moved manually to the other switch, and then the ENUM card re-provisioned with the address of the other EPAP.

SLIC Network Redundancy

Four (4) network interfaces are supported for ENUM: Two (2) interfaces for EPAP communication and two (2) interfaces for signaling. One SLIC card with the ENUM application can connect to two (2) EPAPs and two (2) signaling networks at the same time. Interface A/D will be used for EPAP connectivity, while interface B/C used for the signaling network.

Figure 2-4 SLIC Network Redundancy Model


img/c_slic_redundancy.jpg

SLIC Signaling Network Redundancy

To achieve signaling network redundancy with the ENUM application, operators need to configure parallel UDP connections on both interfaces. One UDP connection per interface will be possible with a SLIC card running the ENUM application. If one interface/switch goes down, the operator needs to switch the traffic to another port/switch.

Figure 2-5 SLIC Card Signaling Network Redundancy


img/c_enum_slic_signaling_redundancy.jpg

SLIC Private Network Redundancy

A SLIC card running the ENUM application will connect to EPAP using ports A and D to support redundancy. The RTDB data will be downloaded in the same manner as on E5-SM8G-B cards.

The difference between the EPAP connectivity on a SLIC card and E5-SM8G-B card is that, upon the failure of one switch or port, the SLIC card starts data download via another switch or port in the same manner as data downloads for the SCCP application.

Note:

Failure of a port on a single SLIC card (out of many) will not cause the card to download via another port until all the cables are disconnected from the active EPAP.

Figure 2-6 SLIC Card Private Network Redundancy


img/c_enum_slic_private_redundancy.jpg

ENUM Connection States

The ENUM server connection is based on UDP socket and it has three states as shown in Table 2-1.

Table 2-1 ENUM Connection States

State Description

OPEN

ENUM connection is set OPEN=YES by OAM. The ENUM server UDP socket is created and listening for incoming ENUM packets

CLOSING

ENUM connection is set OPEN=NO by OAM. Transit state to process outstanding messages before moving to Closed state. All incoming ENUM requests are rejected in this state.

CLOSED

ENUM server UDP socket is closed.

The ENUM card is not allowed to be in the In-Service (IS-NR) state unless an ENUM server connection is provisioned on the ENUM card. Initially after provisioning a new ENUM server connection, the connection is set to the CLOSED state with OPEN=NO. When OPEN is changed to YES, the ENUM application creates a new UDP socket listening for incoming ENUM Request messages and the connection is changed to the OPEN state. In the OPEN state, the ENUM card is ready to receive and process incoming ENUM traffic. When the ENUM connection is set to OPEN=NO, the connection state transitions to the CLOSING state. In the CLOSING state, new incoming ENUM Request messages are rejected; only outstanding ENUM Response messages are processed and sent back to the client before transitioning to CLOSED state. In the CLOSED state, all incoming ENUM packets are discarded.

Congestion Manager

The UDP protocol used between the ENUM client and server does not support congestion handling. The ENUM application supports congestion detection and alarming for each ENUM connection. Two congestion thresholds can be configured and are derived using the ENUM card TPS as shown in Table 2-2.

Table 2-2 ENUM Congestion Thresholds

Congestion Threshold Value (% of Card TPS) Notes

Congestion Level 1

0 – 100 (Default = 40)

Raise a Minor alarm when the card TPS exceeds Congestion Threshold Level 1.

Congestion Level 2

0 – 100 (Default = 80)

Raise a Major alarm when the card TPS exceeds Congestion Threshold Level 2.

The congestion caused by TPS flow control is handled aaccording to Flow Control.

Flow Control

An ENUM card can process up to 4000 messages per second (4000 TPS). Above the 4000 TPS limit, the ENUM card:

  • may discard the messages
  • notify the client with an ENUM Error Response message if the ENUMOPTS option CNGNTFY = TRUE

  • notify the client with an ENUM Error Response Code configured in the ENUMOPTS option CNGRCODE

    The allowed values for the ENUMOPTS option CNGRCODE are 5 (ENUM_QRY_REFUSED), and 11 to 15. The default value of CNGRCODE is 5. ENUM Error Response messages due to congestion are paced at a rate of one error message per 100 discarded ENUM messages at the application level.

  • peg the measurements for Total Discarded ENUM Messages and Messages Discarded due to Congestion at the application level

    Any incoming message discarded due to the UDP socket receive buffer overflow are silently discarded by the network stack. For those messages, discard measurement are not pegged at the application level. This may cause the Error Response message count to not match exactly the rate of one error message per 100 incoming messages causing congestion.

ENUM DNS Interface

ENUM is a telephone number mapping system designed to locate applicable communication servers on the Internet for servicing a given telephone number using DNS queries. ENUM uses a telephone number translated into URI format that is used in a DNS lookup to to retrieve a DNS record that can be used in Internet communication.

The Domain Name System (DNS) is the method by which Internet addresses in mnemonic form are converted into the equivalent numeric IP address. For example, sunc.scit.wlv.ac.uk. is converted to 134.220.4.1. To the user and application process this translation is a service provided either by the local host or from a remote host using the Internet. The DNS server (or resolver) may communicate with other Internet DNS servers if the DNS server cannot translate the address itself. The message formats used for exchange of queries and responses between hosts and DNS servers are defined by IETF standards (RFC 1035). Queries and responses can be transferred either by TCP or UDP; the EAGLE ENUM application supports only UDP. Both queries and responses have the same general format, containing up to five individual sections carrying information.

DNS Message Format

All communications inside of the domain protocol are carried in a single format called a message. The top level format of message is divided into five sections. Some sections are empty in certain cases. The five sections are shown below.


+---------------+
|     Header    |
+---------------+
|    Question   | Question for the DNS Server
+---------------+
|     Answer    | Resource Records answering the question
+---------------+
|   Authority   | Resource Records pointing toward an authority
+---------------+
|   Additional  | Resource Records holding additional information
+---------------+

The Header section is always present. The Header section includes fields that specify which of the remaining sections are present, and also specify whether the message is a query or a response, a standard query, or other opcode.

The names of the sections after the Header section are derived from their use in standard queries. The Question section contains fields that describe a question to a DNS Server. These fields are a Query Type (QTYPE), a Query Class (QCLASS), and a Query Domain Name (QNAME). The last three sections are the same format: a list of concatenated Resource Records (RRs) which may be empty. The Answer section contains RRs that answer the question. The Authority section contains RRs that point toward an authoritative DNS Server; the additional records section contains RRs which relate to the query, but are not strictly answers for the question.

Header Section Format

The Header section contains the following fields:


                                 1  1  1  1  1  1
   0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                      ID                       |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                    QDCOUNT                    |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                    ANCOUNT                    |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                    NSCOUNT                    |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                    ARCOUNT                    |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The Header section fields are described in Table 2-3. The total size of the Header section format is 12 octets.

Table 2-3 DNS Header Section Format

Field Type Description

ID

Ushort

This 16-bit identifier is assigned by the program that generates any kind of query. This identifier is copied to the corresponding reply and can be used by the requester to match replies to outstanding queries.

QR

Bitfield

This 1-bit field specifies whether this message is a query (0), or a response (1).

OPCODE

Bitfield

This 4-bit field specifies the kind of query in this message. This value is set by the originator of a query and copied into the response. The values are:

  • 0 - a standard query (QUERY)
  • 1 - an inverse query (IQUERY)
  • 2 - a server status request (STATUS)

Values 3 -15 are reserved for future use.

AA

Bitfield

The Authoritative Answer bit is valid in responses, and specifies that the responding DNS server is an authority for the domain name in question section.

TC

Bitfield

The Truncation bit specifies that this message was truncated due to a message length greater than the length permitted on the transmission channel.

RD

Bitfield

The Recursion Desired bit may be set in a query and is copied into the response. If the RD bit is set, the DNS server is directed to pursue the query recursively. Recursive query support is optional.

RA

Bitfield

The Recursion Available bit is set or cleared in a response, and denotes whether recursive query support is available in the DNS server.

Z

Bitfield

These bits are reserved for future use. These bits nust be zero in all queries and responses.

RCODE

Bitfield

The 4-bit Response Code field is set as part of responses. The values are:

  • 0 - No error condition
  • 1 - Format error: The DNS server was unable to interpret the query.
  • 2 - Server failure: The DNS server was unable to process this query due to a problem with the DNS server.
  • 3 - Name Error: This code is only for responses from an authoritative DNS server. This code signifies that the domain name referenced in the query does not exist.
  • 4 - Not Implemented: The DNS server does not support the requested kind of query.
  • 5 - Refused: The DNS server refuses to perform the specified operation for policy reasons. For example, a DNS server may not wish to provide the information to the particular requester, or a DNS server may not wish to perform a particular operation (example: zone transfer) for particular data.

Values 6-15 are reserved for future use.

QDCOUNT

Ushort

This field is an unsigned 16-bit integer specifying the number of entries in the Question section.

ANCOUNT

Ushort

This field is an unsigned 16-bit integer specifying the number of resource records in the Answer section.

NSCOUNT

Ushort

This field is an unsigned 16-bit integer specifying the number of DNS server resource records in the Authority Records (Name Server) section.

ARCOUNT

Ushort

This field is an unsigned 16-bit integer specifying the number of resource records in the Additional Records section.

Question Section Format

The Question section is used to carry the question in most queries. The question includes the parameters that define what is being asked. The Question section contains QDCOUNT (usually one) entries, each with the following format:


                                 1  1  1  1  1  1
   0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                                               |
 |                     QNAME                     |
 |                                               |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                     QTYPE                     |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                     QCLASS                    |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The Question section fields are described in Table 2-4.

Table 2-4 DNS Question Section Format

Field Type Description

QNAME

Char[]

This field is a domain name represented as a sequence of labels, where each label consists of a length octet followed by that number of octets. The domain name terminates with the zero length octet for the null label of the root. Note that this field may be an odd number of octets; no padding is used.

QTYPE

Ushort

This field is a 2-octet code which specifies the type of the query. The values for this field include all codes valid for a TYPE field, together with more general codes which can match more than one type of RR.

QCLASS

Ushort

This field is a 2-octet code that specifies the class of the query. For example, the QCLASS field is IN for the Internet.

Resource Record Format

The Answer section, Authority section, and Additional section share the same format which is a variable number of Resource Records. The number of Resource Records is specified in the corresponding field in the header - ANCOUNT, NSCOUNT, ARCOUNT. A Resource Record (RR) has the following format:


                                 1  1  1  1  1  1
   0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                                               |
 |                                               |
 |                      NAME                     |
 |                                               |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                      TYPE                     |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                     CLASS                     |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                      TTL                      |
 |                                               |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                   RDLENGTH                    |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
 |                     RDATA                     |
 |                                               |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The Resource Record fields are described in Table 2-5.

Table 2-5 DNS Resource Record Format

Field Type Description

NAME

Char[]

This field is a domain name to which this resource record pertains.

TYPE

Ushort

This 2-octet field contains one of the Resource Record type codes. This field specifies the meaning of the data in the RDATA field.

CLASS

Ushort

This 2-octet field specifies the class of the data in the RDATA field.

TTL

Ulong

This field is a 32-bit unsigned integer that specifies the time interval in seconds that the Resource Record may be cached before it should be discarded. Zero values are interpreted to mean that the Resource Record can be used only for the transaction in progress, and should not be cached.

RDLENGTH

Ushort

This field is a 16-bit unsigned integer that specifies the length in octets of the RDATA field.

RDATA

Uchar[]

This variable length string of octets describes the resource. The format of this information varies according to the TYPE and CLASS of the Resource Record. For example, if the TYPE = A and CLASS = IN, the RDATA field is a 4-octet ARPA Internet address.

NAPTR Resource Record Format

The DNS type code for NAPTR is 35. The packet format for the NAPTR Resource Record (RR) is:


                                 1  1  1  1  1  1
   0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                     ORDER                     |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                   PREFERENCE                  |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                     FLAGS                     |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                   SERVICES                    |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                    REGEXP                     |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                  REPLACEMENT                  |
 |                                               |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The NAPTR RR packet format fields are described in Table 2-6.

Table 2-6 NAPTR Resource Record Format

Field Type Description

ORDER

Ushort

This field is a 16-bit unsigned integer specifying the order in which the NAPTR records must be processed to accurately represent the ordered list of Rules. The ordering is from lowest to highest. If two records have the same order value, then they are considered to be the same rule and should be selected based on the combination of the Preference values and Services offered.

PREFERENCE

Ushort

This field is a 16-bit unsigned integer that specifies the order in which NAPTR records with equal ORDER values should be processed. Low numbers are processed before high numbers.

Although the field is identified as "Preference" in deference to DNS terminology, this field is equivalent to the Priority value in the DDDS Algorithm. This field is similar to the Preference field in an MX record, and is used to allow domain administrators to direct clients towards more capable hosts or lighter weight protocols. A client may look at records with higher preference values if the client has a valid reason (example: not capably supporting a particular protocol or service).

The important difference between ORDER and PREFERENCE fields is that when a match is found the client must not consider records with a different ORDER but the client may process records with the same ORDER but different PREFERENCEs. The only exception to this is noted in the second important note in the DDDS algorithm specification concerning allowing clients to use more complex Service determination between steps 3 and 4 in the algorithm. PREFERENCE is used to communicate a higher quality of service to rrules that are considered the same from an authority standpoint but not from a simple load-balancing perspective.

Note that DNS contains several load-balancing mechanisms. If load balancing among otherwise equal services is needed, then methods such as SRV records or multiple A records should be utilized to accomplish load balancing.

FLAGS

Char[]

This field is a character string containing flags to control aspects of the rewriting and interpretation of the fields in the record. Allowable values are single alphanumeric characters (A-Z, 0-9). Alphabetic characters can be upper case or lower case with no significance. The field can be empty. The application must specify how it is using this database to define the flags in this field, and must define which flags are terminal and which are not.

SERVICES

Char[]

This field is a character string that specifies the service parameters applicable to this delegation path. The application must specify the values found in this field.

REGEXP

Char[]

This field is a character string containing a substitution expression that is applied to the original string held by the client in order to construct the next domain name to lookup.

As stated in the DDDS algorithm which provides the syntax of this field, the regular expressions must not be used in a cumulative fashion; they can be applied only to the original string held by the client and never to the domain name produced by a previous NAPTR rewrite.

REPLACEMENT

Char[]

This field is a domain name which is the next domain name to query, depending on the potential values found in the FLAGS field. The REPLACEMENT field is used when the regular expression is a simple replacement operation. Any value in this field must be a fully-qualified domain name. Name compression cannot be used for this field.

The REPLACEMENT field and the REGEXP field together make up the Substitution Expression in the DDDS Algorithm. This field exists for reasons of historical optimization, specifically for DNS compression. The fields are mutually exclusive. If a record is returned that has values for both fields, then it is considered to be in error and either should be ignored or an error returned.

NS Resource Record Format

NSDNAME is a domain name which specifies a host which should be authoritative for the specified class and domain.


 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                   NSDNAME                     |
 |                                               |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

CNAME Resource Record Format

CNAME is a domain name which specifies the canonical or primary name for the owner. The owner name is an alias.


 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                     CNAME                     |
 |                                               |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

ENUM Query Format

The ENUM application (Tier 1 NAPTR) expects a DNS Query with the formats for the Header and Question sections, as shown respectively in Table 2-7 and Table 2-8:

Table 2-7 ENUM Query Section Format - Header Section

Data Field Description Possible Values

ID

This 16-bit identifier is used to correlate queries and responses.

any valid 16-bit number

QR

The Query/Response field must be 0.

0 = Query

OPCODE

The OPCODE field specifies the type of query and must be 0.

0 = Standard Query

AA

The Authoritative Answer bit is ignored by the ENUM application.

0 or 1

TC

The Truncation bit must be 0.

0

RD

The Recursion Desired bit may be 0 or 1.

0 or 1

RA

The Recursion Available bit may be 0 or 1.

0 or 1

Z

Reserved; must be 0

0

RCODE

The Response Code field must be 0 in a query.

0

QDCOUNT

The Question section count must be 1.

1

ANCOUNT

The Answer section count must be 0.

0

NSCOUNT

The Authority Records (Name Server) section count is ignored.

0

ARCOUNT

The Additional Records section count is ignored.

0

Table 2-8 ENUM Query Section Format - Question Section

Data Field Description Possible Values

QNAME

This field is the Telephone Number to be queried in an e164.arpa format.

any valid e164.arpa format Telephone Number

QTYPE

This field is the type of Question.
  • NAPTR (35)
  • NS (2)
  • CNAME (5)

QCLASS

This field is the class of Question.

1 (Internet)

ENUM Response Format

The ENUM application (Tier 1 NAPTR) responds with a DNS Response with the following formats for the Header, Question, Answer, and Authority sections, if no errors occurred and the carrier associated with the telephone number was found:

Table 2-9 ENUM Response Format - Header Section

Data Field Description Possible Values

ID

This identifier is used to correlate queries andresponses.

The ID from the Query is placed in the ID field of the Response.

QR

The Query/Response field must be 1.

1 = Response

OPCODE

The OPCODE field specifies the type of Query and must be 0.

0 = Standard Query

AA

The Authoritative Answer bit must be 1.

1

TC

The Truncation bit must be 0.

0

RD

The Recursion Desired bit depends on the Query RD value. The RD from the Query is placed in the RD field of the Response.

0 or 1

RA

The Recursion Available bit must be 0. Recursion is not supported.

0

Z

Reserved; must be 0

0

RCODE

The Response Code depends on the error. (Table 2-13)

0, 1, 2, 3, 4, 5, 11 - 15

QDCOUNT

The Question section count must be 1.

1

ANCOUNT

The Answer section count can be up to 2.

0, 1, or 2

NSCOUNT

The Authority Records (Name Server) section count can be 0 or 1.

0 or 1

ARCOUNT

The Additional Records section count is ignored.

0

The Question section in the ENUM Response message reflects the Question section of the received Query.

Table 2-10 ENUM Response Format - Question Section

Data Field Description Possible Values

QNAME

This field is the Telephone Number in an e164.arpa format.

valid e164.arpa format Telephone Number of Query

QTYPE

This field is the type of Question.
  • NAPTR (35)
  • NS (2)
  • CNAME (5)

QCLASS

This field is the class of Question.

1 (Internet)

The DNS Response from the ENUM application may include multiple Answer Response Records with the following format.

Table 2-11 ENUM Response Format - Answer Section

Data Field Description Possible Values

NAME

This field is the Telephone Number in an e164.arpa format.

valid e164.arpa format Telephone Number of Query

TYPE

This field contains the Resource Record type code.

  • NAPTR (35)
  • NS (2)
  • CNAME (5)

CLASS

The CLASS must be 1 for Internet.

1

TTL

The Time to Live for a Resource Record to be cached in seconds is 0.

0

RDLENGTH

This field is the length in octets of the RDATA field.

variable

RDATA

The Resource Data field is a variable length string of octets that describes the resource.

variable

ORDER

This field specifies the order in which NAPTR records are processed. The lowest number is the highest order.

variable; 16-bit unsigned number (0 - 63535)

PREFERENCE

This field specifies the order in which NAPTR records with identical ORDER values are processed. The lowest number is the highest order.

variable; 16-bit unsigned number (9 - 63535)

FLAGS

This field controls the rewriting and interpretation of the record.

U - Terminal Rule

SERVICES

This field specifies the protocol associated with a service.

E2U+pstn:tel

E2U+pstn:sip

E2U+SIP

REGEXP

This field specifies the substitution expression applied to the original string.

!^.*$!sip:\1;npdi;​rn=\1%40gw.example.com;user=phone!.

!^.*$!sip:+1442079460148@example.com!

The Authority Section contains the name of the host on which the ENUM server (Tier 1 NAPTR ) is running as authoritative for the requested query.

Table 2-12 ENUM Response Format - Authority Section

Data Field Description Possible Values

NAME

This field is the domain name to which this Resource Record pertains.

1.e164.arpa

TYPE

The Resource Record TYPE must be 2.

2 = authoritative DNS server

CLASS

The CLASS of this Query must be 1 for Internet.

1

TTL

The Time to Live for a Resource Record to be cached in seconds is 0.

0

RDLENGTH

Rhis field in the length of the RDATA field

variable

RDATA

This field is the resource data.

variable

hostname

 This is the hostname of the Tier 1 NAPTR ENUM Server

variable

The ENUM application uses the following response codes when responding to erroneous queries. RCODES values 6 - 10 are reserved for future use.

Table 2-13 ENUM Error Response Codes (RCODEs)

RCODE Name Error

0

No Error

Query processed successfully

1

Format Error

QR field other than 0 (a response)

1

Format Error

Could not parse Query

2

Server Failure

Database inaccessible

3

NXDomain

QNAME-domain does not match what is provisioned

4

Not Implemented

Opcode value other than 0 (not a standard DNS Query)

4

Not Implemented

TC value other than 0 (Truncated Queries are not required to be supported.)

4

Not Implemented

Z value other than 0 (Z is reserved for future use.)

4

Not Implemented

QDCOUNT value other than 1

4

Not Implemented

QTYPE value other than NAPTR (35), CNAME(5), or NS (2)

4

Not Implemented

QCLASS value other than 1

5, 11 - 15

Query Refused

Query refused due to inbound congestion

The ENUM application responds to badly-formed queries with an error response with the following format:

Table 2-14 ENUM Error Response - Header Section

Data Field Description Possible Values

ID

This identifier is used to correlate queries andresponses.

The ID from the Query is placed in the ID field of the Response.

QR

The Query/Response field must be 1.

1 = Response

OPCODE

The OPCODE field specifies the type of Query and must be 0.

0 = Standard Query

AA

The Authoritative Answer bit must be 1.

1

TC

The Truncation bit must be 0.

0

RD

The Recursion Desired bit depends on the Query RD value. The RD from the Query is placed in the RD field of the Response.

0 or 1

This bit is ignored regardless of its value.

RA

The Recursion Available bit must be 0. Recursion is not supported.

0

Z

Reserved; must be 0

0

RCODE

The Response Code depends on the error. (Table 2-13)

0, 1, 2, 3, 4, 5, 11 - 15

QDCOUNT

The Question section count must be 1.

1

ANCOUNT

The Answer section count must be 0.

0

NSCOUNT

The Authority Records (Name Server) section count can be 0 or 1.

0 or 1

ARCOUNT

The Additional Records section count is ignored.

0

ENUM Application

The ENUM application task on each ENUM card provides the following functions:

  • Receive ENUM Query messages
  • Verify client IP addresses
  • Validate incoming ENUM Queries
  • Perform lookups in Number Portability database (RxDB) and ENUM database
  • Create and send ENUM Response messages

ENUM Query Screening

The ENUM application allows ENUM Query messages to be received from only trusted ENUM clients. The ENUMACL table is used to provision the IP addresses of trusted ENUM clients. A Query message is discarded and the ENUMACLDISC measurement is pegged if the Query message is received from a client other than a trusted ENUM client stored in the ENUMACL table. The ENUMACL table has a maximum capacity of 100 IPADDR entries.

Table 2-15 ENUMACL Table

Field Name Constraints Comments

IPADDR
  • Four numbers in the range 0-255 separated by dots
  • Mandatory

The ENUM client IP address is allowed to query the ENUM server.

Wild Cards (*) in IP Addresses

An ACL IPADDR entry of *.*.*.* is invalid. ACL entries which overlap with other entries with wild cards are not allowed. EAGLE allows the use of wild cards to support IP address ranges covered by an ACL entry as follows:

  • xxx.xxx.xxx.*
  • xxx.xxx.*.*
  • xxx.*.*.*

Table 2-16 ENUMACL Table Example Entries

IPADDR
10.250.80.41
10.250.60.*
10.252.*.*

ENUM Query Validation

The ENUM application validates the incoming ENUM Query message to verify whether the the message conforms to the Query format specified in ENUM Query Format. At a minimum, EAGLE supports validations for the error conditions shown in Table 2-17 to be handled during the validation of ENUM query.

Table 2-17 ENUM Query Validation Errors

Error Condition Response

QR (Query/Response flag) Field in ENUM Query Header = 1

ENUM Error Response with RCODE=1 (Format Error)

OPCODE other than 0 (Not a standard DNS query)

ENUM Error Response with RCODE=4 (Not Implemented)

TC (Truncation Flag) in ENUM Query Header = 1

ENUM Error Response with RCODE=4 (Not Implemented)

TC (Truncation Flag) in ENUM query header = 0 and query packet size > 512 bytes

ENUM Error Response with RCODE=4 (Not Implemented)

Z (Reserved Field) in ENUM Query Header = 1

ENUM Error Response with RCODE=4 (Not Implemented)

RCODE(Response Code) in ENUM Query Header = 1

ENUM Error Response with RCODE=1 (Format Error)

QDCOUNT (Question Count) in ENUM Query Header > 1

ENUM Error Response with RCODE=4 (Not Implemented)

ENUM Query Question Section QNAME field root other than e164.arpa

ENUM Error Response with RCODE=3 (Non-Existent Domain Error)

ENUM Query Question Section QTYPE field other than NAPTR (35), NS (2) or CNAME (5)

ENUM Error Response with RCODE=4 (Not Implemented)

ENUM Query Question Section QCLASS field other than 1 (Internet)

ENUM Error Response with RCODE=4 (Not Implemented)

ENUM Response

The ENUM application generates ENUM Response messages using:

  • Pre-defined values for some of the fields in the Response message
  • Configurable data in the ENUMPROF table
  • Dynamic data resulting from the RxDB lookup, such as Entity ID (RN)

Refer to ENUM Profile Table (ENUMPROF) for details on configurable fields in the ENUMPROF table to be used in building an ENUM response for NAPTR, CNAME and NS Queries.

Pre-defined Fields for NAPTR Response

Table 2-18 describes the pre-defined NAPTR Resource Record (RR) fields.

Table 2-18 Pre-defined Fields for NAPTR Response

Data Field Description Pre-Defined Values

TYPE

Resource Record Type

NAPTR – 35

CLASS

Class of Query (1 for Internet)

1

TTL

Time to Live in seconds for an RR to be cached

0

ORDER

Order in which NAPTR records are processed

16-bit unsigned value (Range = 0 to 63535).

Lowest number = Highest order

10

PREFERENCE

Order in which equal order NAPTR records are processed

100 - If PREF field in the ENUMPROF table = FALSE

10 – if PREF field in the ENUMPROF table = TRUE

FLAGS

Controls rewriting and interpretation of the record

U = Terminal Rule

U

SERVICE TYPE

Supported ENUM services are:

  • E2U+pstn:tel
  • E2U+pstn:sip
  • E2U+SIP

Values defined for SERVICE TYPE in ENUMPROF tables are:

  • PSTNTEL
  • PSTNSIP
  • SIP

The default value is PSTNTEL.

NAPTR Resource Record Regular Expression

NAPTR Resource Record (RR) Regular expression is used to build a URI to be sent to the ENUM client in the NAPTR response. The format used for preparing regular expression in NAPTR is:

  • “!^.*$!<URI>!”

The PSTNSIP URI uses percent encoding for the “@” symbol (%40). Table 2-19 describes the format for Regular expression forming URIs for all services.

Table 2-19 ENUM NAPTR RR Regular Expression Format

Service Ported Non-Ported

PSTNSIP

(INCPREFIX set to NO)

sip:<+Called Party DN>;npdi;RN=<RN from the NPDB lookup>%40<domain name defined in ENUMPROF Table>

sip:<+Called Party DN>;npdi%40<domain name defined in ENUMPROF Table>

PSTNSIP

(INCPREFIX set to YES)

sip:+<DEFCC><RN from the NPDB lookup><Called Party DN>;npdi;RN=<+DEFCC><PREFIX configured in ENUM profile>@<domain name defined in ENUMPROF Table>

sip:+<DEFCC><RN from the NPDB lookup><Called Party DN>;npdi;RN=<+DEFCC><PREFIX configured in ENUM profile>@<domain name defined in ENUMPROF Table>

PSTNTEL

Tel:<+Called Party DN>;npdi;RN=<RN from the NPDB lookup>

Tel:<+Called Party DN>;npdi

SIP

sip:<+Called Party DN>@<domain name defined in ENUMPROF Table>

sip:<+Called Party DN>@<domain name defined in ENUMPROF Table>

Pre-defined Fields for NS Response

Table 2-20 describes the NS Resource Record (RR) fields which are pre-defined.

Table 2-20 ENUM NS Response Pre-defined Fields

Data Field Description Pre-Defined Values

TYPE

Resource Record Type

2

CLASS

Class of Query (1 for Internet)

1

TTL

Time to Live in seconds for an RR to be cached

0

Pre-defined Fields for CNAME Response

Table 2-21 describes the CNAME Resource Record (RR) which are pre-defined.

Table 2-21 ENUM CNAME Response Pre-defined Fields

Data Field Description Pre-Defined Values

TYPE

Resource Record Type

5

CLASS

Class of Query (1 for Internet)

1

TTL

Time to Live in seconds for an RR to be cached

0

ENUM Database

To generate a Response for an ENUM Query, the ENUM application performs two database lookups:

  • Number Portability RxDB lookup to find the matching Entity ID for a DN included in the incoming Query
  • ENUM Database lookup to generate an ENUM response using the Entity Id as the key

The ENUM Database is composed of three tables on the EAGLE which store the data needed for generating ENUM Response based on the incoming DN in the ENUM Query.

  • ENUM Profile Selection table (ENUMPRID)
  • ENUM DN Block table (ENUMDNBK)
  • ENUM Profile table (ENUMPROF)

The ENUMACL table which stores the IP Addresses of trusted ENUM clients is described in ENUM Query Screening.

Another table used with the ENUM Mobile Number Portability and Tier One Address Resolution (ENUM) feature is the ENUM Options (ENUMOPTS) table which contains the system-wide configuration information required for the operation of the ENUM application. The ENUMOPTS table is part of the EGLEOPTS table.

ENUM Profile Selection Table (ENUMPRID)

The ENUM Profile Selection table (ENUMPRID) provides the mapping between Entity ID and ENUM Profile Selection ID, which is used as the lookup key in the ENUM Profile table (ENUMPROF). The primary advantage of the ENUMPRID table is the flexibility provided to dynamically change the ENUM Response Resource Record format (NAPTR, NS, or CNAME) for a specific Entity ID without making provisioning changes in the Number Portability RxDB using LSMS.

The ENUMPRID table allows a single Entity ID to be mapped to a maximum of four ENUM Profile IDs. Of the maximum of four ENUM Profile IDs, a maximum of two are for NAPTR records, one is for an NS record, and one is for a CNAME record from the ENUM Profile table (ENUMPROF). At least one Profile name must be assigned to an Entity ID entry in the ENUMPRID table. The maximum number of entries allowed in the ENUMPRID table is 2048.

Table 2-22 ENUMPRID Table Parameters

Name Constraints Comment

ENTITYID

  • digit string
  • 1-15 digits
  • mandatory

This field is an individual Entity ID found from the DN or DN Block lookup in the Number Portability RxDB.

PRN1

  • character string
  • 10 characters
  • 1 alphabetic character followed by 9 alphanumeric characters
  • optional

First Profile Name; PRN1 must be of NS type.

PRN2

  • character string
  • 10 characters
  • 1 alphabetic character followed by 9 alphanumeric characters
  • optional

Second Profile Name; PRN2 must be of CNAME type.

PRN3

  • character string
  • 10 characters
  • 1 alphabetic character followed by 9 alphanumeric characters
  • optional

Third Profile Name; PRN3 must be of NAPTR type.

PRN4

  • character string
  • 10 characters
  • 1 alphabetic character followed by 9 alphanumeric characters
  • optional

Fourth Profile Name; PRN4 must be of NAPTR type.

Table 2-23 ENUMPRID Table Example Entries

ENTITYID PROFILE
1234 PROF1, PROF2
3244 PROF2

ENUM DN Block Profile Table (ENUMDNBK)

The ENUM DN Block Profile table (ENUMDNBK) provides the mapping between DN Blocks and the ENUM Profile Selection ID, which is used as the lookup key in the ENUM Profile table (ENUMPROF). The primary advantage of the ENUMDNBK table is that it provides an ENUM Profile Selection for DNs which are missing from the Individual DN table and the DN Block table in the Number Portability RxDB. Another advantage of the ENUMDNBK table is the flexibility provided to dynamically change the ENUM Response Resource Record format (NAPTR, NS, or CNAME) for a specific DN Block without making provisioning changes in the Number Portability RxDB using LSMS.

The ENUMDNBK table allows a single DN Block to be mapped to a maximum of four ENUM Profile IDs. Of the maximum of four ENUM Profile IDs, a maximum of two are for NAPTR records, one is for an NS record, and one is for a CNAME record from the ENUM Profile table (ENUMPROF). At least one Profile name must be assigned to a DN Block entry in the ENUMDNBK table. The maximum number of entries allowed in the ENUMDNBK table is 4096.

Table 2-24 ENUMDNBK Table Parameters

Name Constraints Comment

SDN

  • digit string
  • 5-15 hex digits
  • mandatory

This field is the Starting DN in a DN Block range.

EDN

  • digit string
  • 5-15 hex digits
  • mandatory

This field is the Last DN in a DN Block range. The number of EDN digits must be identical to the number of SDN digits. The EDN parameter value must be greater than the SDN parameter value.

PRN1

  • character string
  • 10 characters
  • 1 alphabetic character followed by 9 alphanumeric characters
  • optional

First Profile Name; PRN1 must be of NS type.

PRN2

  • character string
  • 10 characters
  • 1 alphabetic character followed by 9 alphanumeric characters
  • optional

Second Profile Name; PRN2 must be of CNAME type.

PRN3

  • character string
  • 10 characters
  • 1 alphabetic character followed by 9 alphanumeric characters
  • optional

Third Profile Name; PRN3 must be of NAPTR type.

PRN4

  • character string
  • 10 characters
  • 1 alphabetic character followed by 9 alphanumeric characters
  • optional

Fourth Profile Name; PRN4 must be of NAPTR type.

Table 2-25 ENUMDNBK Table Example Entries

SDN EDN PROFILE

9194841000

9194841999

PROF1, PROF2

7733548000

7733548999

PROF1

ENUM Profile Table (ENUMPROF)

The ENUM Profile table (ENUMPROF) contains the data needed to generate an ENUM Response for three supported Resource Record formats: NAPTR, NS and CNAME. The Profile ID selected from the Profile Selection table (ENUMPRID) lookup is used as the key to find the matching entry for the ENUM Response. The maximum allowed ENUM Profile Name (PRN) entries in the ENUMPROF table is 2048.

Table 2-26 ENUMPROF Table Parameters

Constraints Comment

PRN

  • character string
  • 10 characters
  • 1 alphabetic character followed by 9 alphanumeric characters
  • mandatory

Profile Name

The Profile Name provides the key for Profile lookup in the ENUMPROF Table.

RTYPE

  • character string
  • valid Response Type value: NAPTR [default], NS, CNAME
  • optional

Response Type

The Response Type determines the type of Response (NAPTR, NS, or CNAME) to send to the ENUM client.

PREF

  • Boolean
  • valid value: YES, NO [default]
  • optional

Preferred Response

Because the ENUM application allows only two NAPTR Resource Records in a single ENUM Response, the Preferred Response (PREF) parameter determines the values for the Order and Preference fields to be encoded for each NAPTR Resource Record. The value of this field does not apply if only one NAPTR Resource Record is in a single ENUM Response. The PREF parameter is valid for only the NAPTR Response Type.

SPARM

  • character string
  • valid values: PSTNTEL [default], PSTNSIP, SIP
  • optional

Service Parameter (Service Type)

The ENUM application supports only three ENUM Services: E2U+pstn:tel, E2U+pstn:sip, E2U+SIP. The SPARM parameter is valid for only the NAPTR Response Type.

RRDOMAIN

  • character string
  • valid values: 0-9 A-Z - .
  • Default value is no character (blank)
  • 64 characters maximum
  • optional, except with RTYPE=NAPTR and SPARM=PSTNSIP/SIP when this parameter is mandatory

Domain Name in Regular Expression

The Domain Name in Regular Expression is the domain name used in SIP URI for both ported and non-ported numbers. The RRDOMAIN parameter is valid for only the NAPTR Response Type.

RPDOMAIN

  • character string
  • valid values: 0-9 A-Z - .
  • Default value is no character (blank)
  • 64 characters maximum
  • optional, except with RTYPE=NS and RTYPE=CNAME when this parameter is mandatory

Replacement Domain Name

This field is used for:
  • Replacement domain name in NAPTR record
  • Domain name of the DNS server in the NS record
  • Canonical Name of domain server in the CNAME records
PREFIX
  • Hexadecimal digits valid
  • Values: 0 - fffff
  • 5 digits maximum
  • optional

Prefix digits for NAPTR Regular expression

The prefix digits are inserted as RN in regular expression in response to NAPTR queries. This case applies when INCPREFIX option in ENUMOPTS is set to YES and the NAPTR service configured in ENUM PROFILE is PSTNSIP.

Table 2-27 ENUMPROF Table Example Entries

PRN RTYPE PREF SPARM RRDOMAIN RPDOMAIN PREFIX

Default

NS

NO

Gw.ns1example.com

PROF1

NAPTR

NO

PSTNTEL

PROF2

NAPTR

YES

PSTNSIP

Gw3.nptrexample.com

6002

PROF3

CNAME

NO

Gw4.cnexample.com

PROF4

NS

NO

Gw4.nsexample.com

PROF5

NAPTR

YES

SIP

Gw3.nptrexample.com

Default Profile

Upon start-up, the ENUM application initializes the first entry in the ENUM Profile table (ENUMPROF) as a default profile with these values:

  • Profile Name (PRN) = default
  • Response Type (RTYPE) = NAPTR
  • Service Parameter (SPARM) = PSTNTEL

These provisioning rules apply to the ENUM default profile:

  • Default profile cannot be deleted.
  • Response Type (RTYPE) can be changed only for the default profile and no other profiles.
  • Response Type (RTYPE) = CNAME is invalid for the default profile.
  • Changing Response Type (RTYPE) = NS to Response Type (RTYPE) = NAPTR requires that the SPARM parameter must remain set to the default value of PSTNTEL.
  • Changing Response Type (RTYPE) = NAPTR to Response Type (RTYPE) = NS requires that the Replacement Domain (RPDOMAIN) be provisioned, and the RRDOMAIN, PREF, PREFIX, and SPARM parameters must be set to blank values.

ENUM Options Table (ENUMOPTS)

The ENUM Options table (ENUMOPTS) contains the system-wide configuration information required for the operation of the ENUM application. The ENUMOPTS table is part of the EGLEOPTS table.

Table 2-28 ENUMOPTS Table Parameters

Name Constraints Comment

MAXDNDIGS

  • integer
  • range: 5 - 15
  • default value: 15

Maximum Number of Digits from an Incoming ENUM Query

If the incoming ENUM Query has a DN with the number of digits exceeding MAXDNDIGS, then only the first MAXDNDIGS digits will be used for lookup in the RxDB DN and DN Block tables.

CONGLVL1

  • integer
  • range: 1 - 99
  • default value: 40

ENUM Card Congestion Threshold Level 1

CONGLVL2

  • integer
  • range: 2 - 100
  • default value: 80

ENUM Card Congestion Threshold Level 2

CNGNTFY

  • Boolean
  • range: YES, NO
  • default value: NO

Congestion Notification Flag

CNGRCODE

  • integer
  • range: 5, 11 - 15
  • default value: NO

RCODE Values in ENUM Error Response

The RCODEs are sent due to congestion on the ENUM card.

  • 5 = ENUM_QRY_REFUSED
  • 11 - 15 = USER CONFIGURABLE

EXCLUDESP

  • Boolean
  • range: YES, NO
  • default value: NO

If EXCLUDESP is set to NO and the RxDB look up for a DN in individual DN table or DN Block table results in SP entity Id, that SP entity Id will be used as the key to do lookup in the ENUM profile selection Table.

If EXCLUDESP is set to YES and the RxDB look up for a DN in the individual DN table or DN Block table results in an SP entity Id, that SP entity Id will be ignored and treated as no entity Id found for the DN.

RNCONTEXT

  • Boolean
  • range: YES, NO
  • default value: NO

If RNCONTEXT is set to NO and the rn parameter is to be included in the NAPTR response with "tel" URI, the rn value will be preceded by "+" sign, as in: rn=+<msrn digits>.

If RNCONTEXT is set to YES, the parameter RNCONTEXT with a value of <+CountryCode will be included in the ENUM Tel response. The DEFCC value in STPOPTS will be used as CountryCode.

INCPREFIX
  • Boolean
  • range: YES, NO
  • default value: NO
If INCPREFIX option is set to YES, then the regular expression used in ENUM response for NAPTR PSTNSIP service is:
  • The DEFCC and RN from the NPDB lookup are inserted before the called party DN, as"sip: +<DEFCC><RN from the NPDB lookup><Called Party DN>"
  • TheDEFCC and PREFIX parameter configured inENUM PROFILE are inserted after RNtag as"rn=+<DEFCC><PREFIX>"

ENUM Query Processing for MNP

Figure 2-7 and Figure 2-8 show the overall flow of ENUM messages within the ENUM application for Mobile Number Portability (MNP). The flow of ENUM messages within the ENUM application for MNP is described below.

  1. The ENUM Query is received on the ENUM card over the UDP port.
  2. If the incoming Query is received from a client IP address that is not in the Access Control List (ENUMACL table), the ENUM Query is rejected.
  3. The ENUM Query is validated. If the ENUM Query is invalid, then an Error Response is sent to the originator of ENUM Query.
  4. The ENUM Query domain is verified. If the ENUM Query domain is other than E.164 ARPA, then an Error Response is sent to the originator.
  5. The ENUM Query is decoded. Number conditioning is performed on the digits string in the Query to extract the E.164 DN.
  6. Incoming DN Digits as Lookup Key: Determine the number of digits from the incoming DN to be used as a lookup key for both the RxDB and ENUM databases:
    • If the number of digits from the incoming DN is greater than or equal to the MAXDNDIGS option in the ENUMOPTS table, then use the first MAXDNDIGS digits for the lookup key.
    • If the number of digits from the incoming DN is less than the MAXDNDIGS option in the ENUMOPTS table, then use all of the incoming digits in DN as the lookup key.
  7. An RxDB lookup with the lookup key determined in item 6 is performed in the Individual DN table of the RxDB.
  8. If the Incoming DN is found in Individual DN table of the RxDB with an associated Entity ID (RN/SP), use that Entity ID to retrieve the associated Profile ID from the ENUM Profile Selection table (ENUMPRID). If a Profile ID is found, use that to generate the ENUM Response. Otherwise, form the ENUM Response as shown below in Default Profile Response.
  9. If the Incoming DN is found in the Individual DN table of the RxDB without an associated Entity ID (RN/SP), then a lookup is performed in the ENUM DN Block Profile table (ENUMDNBK) with the incoming DN digits determined in item 6 as the lookup key. If the Profile ID is found, then use that to generate the ENUM Response. Otherwise, form the ENUM Response as shown below in Default Profile Response.
  10. If the incoming DN digits determined in item 6 are not found in the Individual DN table of the RxDB, then an RxDB DN Block table lookup is performed
  11. If the incoming DN digits determined in item 6 are found in the RxDB DN Block table with an associated Entity ID (RN/SP), use that Entity ID to retrieve the associated Profile ID from the ENUM Profile Selection table (ENUMPRID). If a Profile ID is found, use that to generate the ENUM Response. Otherwise, form the ENUM Response as shown below in Default Profile Response.
  12. If the incoming DN digits determined in item 6 are not found in the RxDB DN Block table, then a lookup is performed in the ENUM DN Block Profile table (ENUMDNBK) with the incoming DN digits determined in item 6 as the lookup key. If a Profile ID is found, use that to generate the ENUM Response. Otherwise, form the ENUM Response as shown below in Default Profile Response.

Default Profile Response

If the Default Profile is RTYPE = NS, then send an ENUM Response message with RCODE = 0 and NS in the Authority Section.

If the Default Profile is RTYPE = NAPTR and QTYPE = NAPTR, then send an ENUM NAPTR Response message with RCODE =0.

Otherwise, send an ENUM Error Response message with RCODE=3 (Non-Existent Domain).

See Figure 2-9.

Figure 2-7 ENUM Message Flow for MNP

img/enum_message_flow_for_mnp.png

Figure 2-8 ENUM Message Flow within EAGLE

img/enum_message_flow_in_eagle.png

Figure 2-9 ENUM Default Profile Response

img/enum_default_profile_response.png

MNP RxDB Lookup

For EAGLE with MNP support, the ENUM Response generated for a specific ENUM Query is determined by the result of RxDB lookup and ENUM database lookup. Figure 2-10 shows the various MNP RxDB database lookup scenarios during the processing of the ENUM Query.

Figure 2-10 MNP RxDB Database Lookup

img/enum_mnp_rxdb_lookup.png

ENUM Feature Limitations

  • If the E5-SM8G-B card loses its EPAP connection, the cable from the ENUM card must be moved manually to the other switch and the ENUM card re-provisioned with the IP address of the other switch.
  • If the EPAP database connection is lost, the ENUM card continues to process traffic with the copy of the database it had before the connection was lost, even if the database is stale.
  • If the Signaling Network interface on an E5-SM8G-B card stops functioning, the ENUM traffic corresponding to that Signaling Network interface is discarded.
  • If the ENUM application stops functioning on an ENUM card, all open ENUM transactions handled by that card are lost.
  • Load-balancing of ENUM on the EAGLE is not supported.
  • STC Monitoring and Fast Copy are not supported for ENUM Traffic.
  • The EPAP Data Split feature must be turned on at the EAGLE with 240M EPAP database (120M DNs + 120 M IMSIs) to download the EPAP database on the ENUM card and bring the ENUM card to an in-service state (IS-NR).

  • If PREFIX parameter is configured in an ENUM PROFILE entry, but INCPREFIX option is set to NO in ENUMOPTS, then the PREFIX configured will not be used in the URI of the regular expression of ENUMNAPTR response.

ENUM Measurement Limitations

The measurement registers of ENUM-based reports store a maximum count of 4,294,967,295, due to the size of the register. An additional measurement peg above this limit rolls over the register count to 0.

This limitation constrains the number of ENUM cards in the system running at the maximum of 4000 TPS per ENUM card or the maximum TPS value of the maximum number of allowed ENUM cards (16) in the system.

  • A maximum of 12 ENUM card can process at the maximum of 4000 TPS per card in the system without exceeding the count capacity.
  • The maximum number of allowed ENUM cards (16) in the system can run at a maximum of 3100 TPS per card in the system without exceeding the count capacity.
  • The maximum number of allowed ENUM cards (16) running at the maximum of 4000 TPS per card in the system can run for 18 hours before the count capacity is exceeded.
This measurement register limitation does not affect the processing of traffic. If the limits described above are not respected, then the value of the measurement register will roll over after reaching its maximum value and the peg count will be incorrect.

Hardware Requirements

The ENUM Mobile Number Portability and Tier One Address Resolution (ENUM) feature is supported on the E5-SM8G-B or SLIC card. A maximum of 16 E5-SM8G-B or SLIC cards per EAGLE can be configured as ENUM cards.

EPAP: An EPAP system can support up to 32 Service Module cards (E5-SM8G-B or SLIC cards). Sixteen of the E5-SM8G-B or SLIC cards can be configured as ENUM cards running the ENUM64 GPL. EPAP-related features that perform an RxDB lookup require Service Module cards (E5-SM8G-B or SLIC cards) running the SCCPHC application.

A Third Party Load Balancer product is required to achieve load-sharing and fault tolerance for the ENUM application.

ENUM Card

The ENUM card is an E5-SM8G-B or SLIC card running the ENUM64 GPL.

On the E5-SM8G-B card, Ethernet Interface A is used for EPAP connectivity and Ethernet Interface B is used for the Signaling Network. Table 2-29 and Table 2-30 describe LED operations for the Ethernet Interfaces on E5-SM8G-B cards.

Table 2-29 E5-SM8G-B Faceplate IP Interface/Logical Link Status LED Operation for Port A

IP Interface Status EPAP Connection
EPAP Connection Status PORT A LED ACT A LED
IP port not configured N/A Off Off
Card inhibited
Cable removed and/or not synched N/A Red Red
Sync and/or act-ip-lnk IP connection down Green (100 Mbps) / Amber (1 Gbps) Red
IP connection up Green (100 Mbps) / Amber (1 Gbps) Green
dact-ip-lnk N/A Green Red

Table 2-30 E5-SM8G-B Faceplate IP Interface/Logical Link Status LED Operation for Port B

IP Interface Status Signaling Connection
Link/Connection Status PORT B LED ACT B LED
IP port not configured N/A Off Off
Card inhibited
Cable removed and/or not synched N/A Red Red
Sync Not configured Green Red
Sync and/or act-ip-lnk Configured but ENUM UDP connection CLOSED (open=no) Green Red
ENUM UDP Connection is ACTIVE (open=yes) Green Green
dact-ip-lnk N/A Green Red

On the SLIC card, the Ethernet Interfaces 1 and 4 (mapped to ports A and D, respectively, are used for EPAP connectivity and Ethernet Interfaces 2 and 3 (mapped to ports B and C, respectively) are used for the Signaling Network. As shown in Figure 2-11, backplane DB26 ports A and B are labeled on the backplane for each slot of the shelf (that is, Port <slot number> A and Port <slot number> B). Backplane adaptors (part number 830-1102-03) are attached to backplane ports A and B. The adaptor connected to backplane port A supports the port A Ethernet interface through adaptor port P3, and the adaptor connected to backplane port B supports the port B Ethernet interface through adaptor port P3.

Figure 2-11 SLIC ENUM Card - Ethernet Interface Connections and Status LEDs


img/slic_enum.jpg

Figure 2-11 also shows the status LEDs 1 and 3 that are on the SLIC faceplate, and their associations with the A and B Ethernet interface ports. The status LEDs on the SLIC faceplate are pictured in Figure 2-12.

Figure 2-12 SLIC Faceplate Status LEDs


img/slic_no_lights2.png

Table 2-31 and Table 2-32 describe LED operations for the Ethernet Interfaces on SLIC cards.

Table 2-31 SLIC Front Faceplate IP Interface/Logical Link Status LED Operation for Ports A and D (represented by LED 1 and 4)

IP Interface Status EPAP Connection Status on IP Port A EPAP Connection
PORT LED LINK LED
IP port not configured N/A Off Off
Card inhibited
Cable removed and/or not synched N/A Red Red
Sync and/or act-ip-lnk IP connection down Green (100 Mbps) / Amber (1 Gbps) Red
IP connection up Green (100 Mbps) / Amber (1 Gbps) Green
dact-ip-lnk N/A Green Red

Table 2-32 SLIC Front Faceplate IP Interface/Logical Link Status LED Operation for Ports B and C (represented by LED 2 and 3)

IP Interface Status Signaling Link/Connection Status on IP Port B Signaling Connection
PORT LED LINK LED
IP port not configured N/A Off Off
Card inhibited
Cable removed and/or not synched N/A Red Red
Sync Not configured Green Red
Sync and/or act-ip-lnk Configured but ENUM UDP connection CLOSED (open=no) Green Red
ENUM UDP Connection is ACTIVE (open=yes) Green Green
dact-ip-lnk N/A Green Red