BỘ GIÁO DỤC VÀ ĐÀO TẠO

TRƯỜNG ĐẠI HỌC KỸ THUẬT CÔNG NGHỆ TP.HCM

KHOA CÔNG NGHỆ THÔNG TIN
MẠNG MÁY TÍNH

ĐỒ ÁN CHUYÊN NGÀNH

IP OVER ATM

SVTH: ĐƯỜNG CÔNG LÂM 103102082

NGUYỄN VĂN ĐÔNG MINH
TRẦN QUANG HẢI ĐĂNG
GVHD:

TP.HỒ CHÍ MINH

2007
 BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƯỜNG ĐẠI HỌC KỸ THUẬT CÔNG NGHỆ TP.HCM
KHOA CÔNG NGHỆ THÔNG TIN
MẠNG MÁY TÍNH

ĐỒ ÁN CHUYÊN NGÀNH

IP OVER ATM

SVTH: ĐƯỜNG CÔNG LÂM 103102082

NGUYỄN VĂN ĐÔNG MINH
TRẦN QUANG HẢI ĐĂNG
GVHD:

TP.HỒ CHÍ MINH

2007
 BẢNG NHẬN XÉT ĐỒ ÁN CHUYÊN NGÀNH

TÊN ĐỀ TÀI: IP OVER ATM

NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN

……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
………………………………………
……………………………………………………………………………………………
………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
……………………………………………………………………………………………
………………………………………
……………………………………………………………………………………………
………………………………………………………………………………

Giáo viên hướng dẫn

 LỜI CẢM ƠN

Chúng em xin chân thành cảm ơn sự hướng dẫn tận tình của thầy đã
giúp chúng em hoàn thành đồ án này !

MỤC LỤC

LỜI NÓI ĐẦU

CHƯƠNG I: TỔNG QUAN VỀ IP
I.1. TỔNG QUÁT
I.2. CÁC GIAO THỨC TRONG MẠNG IP
I.3. CÁC BƯỚC HOẠT ĐỘNG CỦA GIAO THỨC IP

CHƯƠNG II: TỔNG QUAN VỀ ATM

II.1. THIẾT BỊ VÀ MÔI TRƯỜNG MẠNG ATM
II.1.1. ĐỊNH DẠNG CƠ BẢN CỦA TẾ BÀO ATM
II.1.2. THIẾT BỊ
II.1.3. GIAO DIỆN MẠNG ATM
II.2. ĐỊNH DẠNG PHẦN HEADER CỦA TẾ BÀO ATM
II.3. MÔ HÌNH THAM CHIẾU CỦA ATM
II.3.1. AAL1 (ATM ADAPTATION LAYERS 1)
II.3.2. AAL2
II.3.3. AAL3/4
II.3.4. AAL5
II.4. ĐỊA CHỈ CỦA ATM
II.4.1. MÔ HÌNH ĐỊA CHỈ CỦA MẠNG CON
II.4.2. ĐỊNH DẠNG NSAP CỦA ĐỊA CHỈ ATM
II.4.3. CÁC TRƯỜNG ĐỊA CHỈ CỦA ATM
II.5. THIẾT LẬP TÍN HIỆU VÀ KẾT NỐI ATM
II.5.1. TIẾN TRÌNH THIẾT LẬP KẾT NỐI ATM
II.5.2. Đ ỊNH TUYẾN VÀ ĐIỀU CHỈNH YÊU CẦU KẾT NỐI

CHƯƠNG III: IP OVER ATM

III.1. GIỚI THIỆU
III.1.1. THÁCH THỨC ĐỐI VỚI IP OVER ATM
III.1.2. NHỮNG MÔ HÌNH CỦA IP OVER ATM
III.2. CLIP (CLASSICAL IP OVER ATM)
III.2.1. LOGICAL SUBNET
III.2.2. ATMARP SERVER
III.2.3. SỰ ĐÓNG GÓI DỮLI ỆU
III.3. NHRP (NEXT HOP RESULATION PROTOCOL)
III.4. IP MULTICAST OVER ATM
III.5. LAN EMULATION (LANE)
III.6. MPOA (MULTIPROTOCOL OVER ATM)
III.6.1. MÔI TRƯỜNG CỦA MPOA
 III.6.2. HOẠT ĐỘNG CỦA MPOA
III.7. P AR AND I-PNNI

CHƯƠNG IV: CẤU HÌNH IP OVER ATM

IV.1. CẤU HÌNH CLIP TRONG MÔI TRƯỜNG SVC (switched virtual
circuit)
IV.1.1. CẤU HÌNH MỘT ATM ARP CLIENT
IV.1.2. CẤU HÌNH MỘT ATM ARP SERVER
IV.2. CẤU HÌNH CLIP TRONG MÔI TRƯỜNG PVC(permanent virtual
circuit)

LỜI NÓI ĐẦU

CHƯƠNG I :TỔNG QUAN VỀ IP
I.1. TỔNG QUÁT
Nhiệm vụ chính của giao thức IP là cung cấp khả năng kết nối các mạng con
thành liên kết mạng để truyền dữ liệu, vai trò của IP là vai trò của giao thức tầng mạng
trong mô hình OSI. Giao thức IP là một giao thức kiểu không liên kết (connectionlees) có
nghĩa là không cần có giai đoạn thiết lập liên kết trước khi truyền dữ liệu.
Sơ đồ địa chỉ hóa để định danh các trạm (host) trong liên mạng được gọi là địa chỉ
IP 32 bits (32 bit IP address). Mỗi giao diện trong 1 máy có hỗ trợ giao thức IP đều phải
được gán 1 địa chỉ IP (một máy tính có thể gắn với nhiều mạng do vậy có thể có nhiều
địa chỉ IP). Địa chỉ IP gồm 2 phần: địa chỉ mạng (netid) và địa chỉ máy (hostid). Mỗi địa
chỉ IP có độ dài 32 bits được tách thành 4 vùng (mỗi vùng 1 byte), có thể biểu thị dưới
dạng thập phân, bát phân, thập lục phân hay nhị phân. Cách viết phổ biến nhất là dùng ký
pháp thập phân có dấu chấm (dotted decimal notation) để tách các vùng. Mục đích của
địa chỉ IP là để định danh duy nhất cho một máy tính bất kỳ trên liên mạng.

Do tổ chức và độ lớn của các mạng con (subnet) của liên mạng có thể khác nhau,
người ta chia các địa chỉ IP thành 5 lớp, ký hiệu là A, B, C, D và E. Trong lớp A, B, C
chứa địa chỉ có thể gán được. Lớp D dành riêng cho lớp kỹ thuật multicasting. Lớp E
được dành những ứng dụng trong tương lai.

Netid trong địa chỉ mạng dùng để nhận dạng từng mạng riêng biệt. Các mạng liên
kết phải có địa chỉ mạng (netid) riêng cho mỗi mạng. Ở đây các bit đầu tiên của byte đầu
tiên được dùng để định danh lớp địa chỉ (0 - lớp A, 10 - lớp B, 110 - lớp C, 1110 - lớp D
và 11110 - lớp E).

Ở đây ta xét cấu trúc của các lớp địa chỉ có thể gán được là lớp A, lớp B, lớp C

Cấu trúc của các địa chỉ IP như sau:

Mạng lớp A: địa chỉ mạng (netid) là 1 Byte và địa chỉ host (hostid) là 3 byte.

Mạng lớp B: địa chỉ mạng (netid) là 2 Byte và địa chỉ host (hostid) là 2 byte.
 Mạng lớp C: địa chỉ mạng (netid) là 3 Byte và địa chỉ host (hostid) là 1 byte.

Lớp A cho phép định danh tới 126 mạng, với tối đa 16 triệu host trên mỗi mạng. Lớp này
được dùng cho các mạng có số trạm cực lớn.

Lớp B cho phép định danh tới 16384 mạng, với tối đa 65534 host trên mỗi mạng.

Lớp C cho phép định danh tới 2 triệu mạng, với tối đa 254 host trên mỗi mạng. Lớp này
được dùng cho các mạng có ít trạm.

Hình 7.1: Cấu trúc các lớp địa chỉ IP

Một số địa chỉ có tính chất đặc biệt: Một địa chỉ có hostid = 0 được dùng để hướng tới
mạng định danh bởi vùng netid. Ngược lại, một địa chỉ có vùng hostid gồm toàn số 1
được dùng để hướng tới tất cả các host nối vào mạng netid, và nếu vùng netid cũng gồm
toàn số 1 thì nó hướng tới tất cả các host trong liên mạng

Hình 7.2: Ví dụ cấu trúc các lớp địa chỉ IP

Cần lưu ý rằng các địa chỉ IP được dùng để định danh các host và mạng ở tầng mạng của
mô hình OSI, và chúng không phải là các địa chỉ vật lý (hay địa chỉ MAC) của các trạm
trên đó một mạng cục bộ (Ethernet, Token Ring.).
Trong nhiều trường hợp, một mạng có thể được chia thành nhiều mạng con (subnet), lúc
đó có thể đưa thêm các vùng subnetid để định danh các mạng con. Vùng subnetid được
lấy từ vùng hostid, cụ thể đối với lớp A, B, C như ví dụ sau:

Hình 7.3: Ví dụ địa chỉ khi bổ sung vùng subnetid

Đơn vị dữ liệu dùng trong IP được gọi là gói tin (datagram), có khuôn dạng

Hình 7.4: Dạng thức của gói tin IP

Ý nghĩa của thông số như sau:

VER (4 bits): chỉ version hiện hành của giao thức IP hiện được cài đặt, Việc có
chỉ số version cho phép có các trao đổi giữa các hệ thống sử dụng version cũ và
hệ thống sử dụng version mới.

IHL (4 bits): chỉ độ dài phần đầu (Internet header Length) của gói tin datagram,
tính theo đơn vị từ ( 32 bits). Trường này bắt buột phải có vì phần đầu IP có thể có
độ dài thay đổi tùy ý. Độ dài tối thiểu là 5 từ (20 bytes), độ dài tối đa là 15 từ hay
là 60 bytes.

Type of service (8 bits): đặc tả các tham số về dịch vụ nhằm thông báo cho mạng
biết dịch vụ nào mà gói tin muốn được sử dụng, chẳng hạn ưu tiên, thời hạn chậm
trễ, năng suất truyền và độ tin cậy. Hình sau cho biết ý nghĩ của trường 8 bits này.

Precedence (3 bit): chỉ thị về quyền ưu tiên gửi datagram, nó có giá trị từ 0 (gói
tin bình thường) đến 7 (gói tin kiểm soát mạng).
 D (Delay) (1 bit): chỉ độ trễ yêu cầu trong đó

D = 0 gói tin có độ trễ bình thường

D = 1 gói tin độ trễ thấp

T (Throughput) (1 bit): chỉ độ thông lượng yêu cầu sử dụng để truyền gói tin với
lựa chọn truyền trên đường thông suất thấp hay đường thông suất cao.

T = 0 thông lượng bình thường và

T = 1 thông lượng cao

R (Reliability) (1 bit): chỉ độ tin cậy yêu cầu

R = 0 độ tin cậy bình thường

R = 1 độ tin cậy cao

Total Length (16 bits): chỉ độ dài toàn bộ gói tin, kể cả phần đầu tính theo đơn vị
byte với chiều dài tối đa là 65535 bytes. Hiện nay giới hạn trên là rất lớn nhưng
trong tương lai với những mạng Gigabit thì các gói tin có kích thước lớn là cần
thiết.

Identification (16 bits): cùng với các tham số khác (như Source Address và
Destination Address) tham số này dùng để định danh duy nhất cho một datagram
trong khoảng thời gian nó vẫn còn trên liên mạng.

Flags (3 bits): liên quan đến sự phân đoạn (fragment) các datagram, Các gói tin
khi đi trên đường đi có thể bị phân thành nhiều gói tin nhỏ, trong trường hợp bị
phân đoạn thì trường Flags được dùng điều khiển phân đoạn và tái lắp ghép bó dữ
liệu. Tùy theo giá trị của Flags sẽ có ý nghĩa là gói tin sẽ không phân đoạn, có thể
phân đoạn hay là gói tin phân đoạn cuối cùng. Trường Fragment Offset cho biết
vị trí dữ liệu thuộc phân đoạn tương ứng với đoạn bắt đầu của gói dữ liệu gốc. Ý
nghĩa cụ thể của trường Flags là:

bit 0: reserved - chưa sử dụng, luôn lấy giá trị 0.

bit 1: (DF) = 0 (May Fragment) = 1 (Don't Fragment)

bit 2: (MF) = 0 (Last Fragment) = 1 (More Fragments)

 Fragment Offset (13 bits): chỉ vị trí của đoạn (fragment) ở trong datagram tính
theo đơn vị 8 bytes, có nghĩa là phần dữ liệu mỗi gói tin (trừ gói tin cuối cùng)
phải chứa một vùng dữ liệu có độ dài là bội số của 8 bytes. Điều này có ý nghĩa là
phải nhân giá trị của Fragment offset với 8 để tính ra độ lệch byte.

Time to Live (8 bits): qui định thời gian tồn tại (tính bằng giây) của gói tin trong
mạng để tránh tình trạng một gói tin bị quẩn trên mạng. Thời gian này được cho
bởi trạm gửi và được giảm đi (thường qui ước là 1 đơn vị) khi datagram đi qua
mỗi router của liên mạng. Thời lượng này giảm xuống tại mỗi router với mục đích
giới hạn thời gian tồn tại của các gói tin và kết thúc những lần lặp lại vô hạn trên
mạng. Sau đây là 1 số điều cần lưu ý về trường Time To Live:

Nút trung gian của mạng không được gởi 1 gói tin mà trường này có giá
trị= 0.

Một giao thức có thể ấn định Time To Live để thực hiện cuộc ra tìm tài
nguyên trên mạng trong phạm vi mở rộng.

Một giá trị cố định tối thiểu phải đủ lớn cho mạng hoạt động tốt.

Protocol (8 bits): chỉ giao thức tầng trên kế tiếp sẽ nhận vùng dữ liệu ở trạm
đích (hiện tại thường là TCP hoặc UDP được cài đặt trên IP). Ví dụ: TCP có giá
trị trường Protocol là 6, UDP có giá trị trường Protocol là 17

Header Checksum (16 bits): Mã kiểm soát lỗi của header gói tin IP.

Source Address (32 bits): Địa chỉ của máy nguồn.

Destination Address (32 bits): địa chỉ của máy đích

Options (độ dài thay đổi): khai báo các lựa chọn do người gửi yêu cầu (tuỳ theo
từng chương trình).

Padding (độ dài thay đổi): Vùng đệm, được dùng để đảm bảo cho phần header
luôn kết thúc ở một mốc 32 bits.

Data (độ dài thay đổi): Trên một mạng cục bộ như vậy, hai trạm chỉ có thể liên
lạc với nhau nếu chúng biết địa chỉ vật lý của nhau. Như vậy vấn đề đặt ra là phải
thực hiện ánh xạ giữa địa chỉ IP (32 bits) và địa chỉ vật lý (48 bits) của một trạm.

I.2. CÁC GIAO THỨC TRONG MẠNG IP

Để mạng với giao thức IP hoạt động được tốt người ta cần một số giao thức bổ sung, các
giao thức này đều không phải là bộ phận của giao thức IP và giao thức IP sẽ dùng đến
chúng khi cần.
 Giao thức ARP (Address Resolution Protocol): Ở đây cần lưu ý rằng các địa chỉ
IP được dùng để định danh các host và mạng ở tầng mạng của mô hình OSI, và
chúng không phải là các địa chỉ vật lý (hay địa chỉ MAC) của các trạm trên đó
một mạng cục bộ (Ethernet, Token Ring.). Trên một mạng cục bộ hai trạm chỉ có
thể liên lạc với nhau nếu chúng biết địa chỉ vật lý của nhau. Như vậy vấn đề đặt ra
là phải tìm được ánh xạ giữa địa chỉ IP (32 bits) và địa chỉ vật lý của một trạm.
Giao thức ARP đã được xây dựng để tìm địa chỉ vật lý từ địa chỉ IP khi cần thiết.

Giao thức RARP (Reverse Address Resolution Protocol): Là giao thức ngược với
giao thức ARP. Giao thức RARP được dùng để tìm địa chỉ IP từ địa chỉ vật lý.

Giao thức ICMP (Internet Control Message Protocol): Giao thức này thực hiện
truyền các thông báo điều khiển (báo cáo về các tình trạng các lỗi trên mạng.)
giữa các gateway hoặc một nút của liên mạng. Tình trạng lỗi có thể là: một gói tin
IP không thể tới đích của nó, hoặc một router không đủ bộ nhớ đệm để lưu và
chuyển một gói tin IP, Một thông báo ICMP được tạo và chuyển cho IP. IP sẽ
"bọc" (encapsulate) thông báo đó với một IP header và truyền đến cho router hoặc
trạm đích.

I.3. CÁC BƯỚC HOẠT ĐỘNG CỦA GIAO THỨC IP

Khi giao thức IP được khởi động nó trở thành một thực thể tồn tại trong máy tính
và bắt đầu thực hiện những chức năng của mình, lúc đó thực thể IP là cấu thành của tầng
mạng, nhận yêu cầu từ các tầng trên nó và gửi yêu cầu xuống các tầng dưới nó.

Đối với thực thể IP ở máy nguồn, khi nhận được một yêu cầu gửi từ tầng trên, nó thực
hiện các bước sau đây:

Tạo một IP datagram dựa trên tham số nhận được.

Tính checksum và ghép vào header của gói tin.

Ra quyết định chọn đường: hoặc là trạm đích nằm trên cùng mạng hoặc một
gateway sẽ được chọn cho chặng tiếp theo.

Chuyển gói tin xuống tầng dưới để truyền qua mạng.

Đối với router, khi nhận được một gói tin đi qua, nó thực hiện các động tác sau:

1) Tính chesksum, nếu sai thì loại bỏ gói tin.

2) Giảm giá trị tham số Time - to Live. nếu thời gian đã hết thì loại bỏ gói tin.

3) Ra quyết định chọn đường.

4) Phân đoạn gói tin, nếu cần.

 5) Kiến tạo lại IP header, bao gồm giá trị mới của các vùng Time - to -Live,
Fragmentation và Checksum.

6) Chuyển datagram xuống tầng dưới để chuyển qua mạng.

Cuối cùng khi một datagram nhận bởi một thực thể IP ở trạm đích, nó sẽ thực hiện bởi
các công việc sau:

1) Tính checksum. Nếu sai thì loại bỏ gói tin.

2) Tập hợp các đoạn của gói tin (nếu có phân đoạn)

3) Chuyển dữ liệu và các tham số điều khiển lên tầng trên.

CHƯƠNG II: TỔNG QUAN VỀ ATM

II.1. THIẾT BỊ VÀ MÔI TRƯỜNG MẠNG ATM

Atm là một sự chuyển mạch tế bào và bao gồm nhiều thành phần công nghệ kết
hợp những lợi ích của mạch chuyển (đảm bảo dung lượng và độ trễ của đường truyền là
hằng số) với chuyển mạch gói(linh hoạt và hiệu quả cho lưư lượng truyền không liên
tục). Nó cung cấp băng thông có thể tăng từ một vài Mbps đến nhiều Gbps. Bởi vì đặc
tính không đồng bộ của nó nên ATM hiệu quả hơn những công nghệ đồng bộ, như là
phân chia thời gian thành nhiều phần (time-division multiplexing - TDM.)với TDM, mỗi
người dùng được gán cho một khe thời gian, và không có một khu vực nào có thể gửi
trong cùng khe thời gian đó. Nếu một khu vực có nhiều dữ liệu để gửi , nó chỉ có thể gửi
khi khe thời gian đến lượt,khe thời gian được gửi trống và không được sử dụng. Bởi vì
ATM là hệ thống không đồng bộ, những khe thời gian thì sẵn có yêu cầu thông tin định
dạng nguồn truyền chứa trong phần header của mỗi tế bào ATM.

II.1.1. ĐỊNH DẠNG CƠ BẢN CỦA TẾ BÀO ATM

ATM truyền thông tin có đơn vị kích thước cố định gọi là tế bào. mỗi tế bào gồm
có 53 octets hoặc bytes. 5 bytes đầu tiên chứa thông tin phần header của tế bào và còn lại
48 bytes chứa payload (thông tin của người dùng). Những tế bào nhỏ,chiều dài cố định
thì rất thích hợp để truyền lưu lượng tiếng nói (voice) và video bởi vì lưu lượng truyền thì
không chấp nhận được độ trễ là kết quả từ việc phải chờ đợi gói dũ liệu lớn tải về, bao
gồm cả những thứ khác. Hình 27-2 minh hoạ định dạng cơ bản của một tế bào ATM
Figure 27-2 An ATM Cell Consists of a Header and Payload Data
II.1.2. THIẾT BỊ
Một mạng ATM được xây dựng từ một ATM switch và ATM endpoints.ATM
switch có trách nhiệm chuyển các tế bào xuyên suốt trong một mạng ATM. Công việc của
một ATM switch được định nghĩa là: Nó chấp nhận các tế bào chuyển đến từ một ATM
endpoint hoặc từ ATM switch khác. Sau đó đọc và cập nhật thông tin phần header của tế
bào và nhanh chóng chuyển tế bào đến một giao diện xuất ra về phía đích. Một ATM
endpoint (hoặc hệ thống cuối) chứa một card mạng ATM. Những ví dụ về ATM endpoint
là những trạm làm việc, routers,những đơn vị dịch vụ số (DSUs),những switch trong
mạng Lan, và những bộ mã hoá,giải mã video(CODECS).
Hình 27-3 minh hoạ một mạng ATM được xây dựng từ những ATM switch và ATM
endpoint
Figure 27-3 An ATM Network Comprises ATM Switches and Endpoints

II.1.3. GIAO DIỆN MẠNG ATM

Một mạng ATM bao gồm việc thiết lập những ATM switch được liên kết với
nhau bằng những kết nối điểm-điểm (point-to-point) ATM hoặc bằng những thiết bị ghép
nối. ATM switch hỗ trợ hai loại thiết bị ghép nối chính: UNI và NNI. UNI kết nối những
hệ thống cuối của ATM (như là những máy chủ và router) tới một ATM switch. NNI kết
nối hai ATM switch. Phụ thuộc vào vịệc vị trí switch đặt trong nhà khách hàng hay nơi
công cộng và được quản lý bởi công ty điện thoại,UNI và NNI có thể được chia nhỏ ra
thành những UNI và NNI chung và riêng. Một UNI riêng kết nối một ATM endpoint và
một ATM switch riêng. Phần chung (public) của nó có cùng chức năng kết nối một ATM
endpoint hoặc switch riêng đến một switch chung. Một NNI riêng kết nối hai ATM switch
trong phạm vi giống như việc tổ chức riêng. NNI chung kết nối hai ATM switch trong
phạm vi giống như việc tổ chức chung.
Một phần bổ sung về kỹ thuật là giao diện sóng mang có băng tầng rộng (B-ICI),
kết nối hai switch chung từ những nhà cung cấp dịch vụ khác nhau.
Hình 27-4 minh hoạ giao diện chi tiết kỹ thuật ATM cho những mạng chung và riêng

CSU/DSU

II.2. ĐỊNH DẠNG PHẦN HEADER CỦA TẾ BÀO ATM

Phần header của tế bào ATM là một trong hai dạng sau: UNI hoặc NNI. Phần
header của UNI được sự dụng cho việc giao tiếp giữa ATM endpoint và ATM switch
trong những mạng ATM riêng. Phần header của NNI được sử dụng để giao tiếp giữa các
ATM switch.
Hình 27-5 mô tả dạng cơ bản của tế bào ATM, định dạng phần header của tế bào ATM
UNI, và định dạng phần header của tế bào ATM NNI.
 Không giống như UNI, phần hearder của NNI không bao gồm trường GFC
(Generic Flow Control). Ngoài ra phần header của NNI còn có trường VPI (virtual path
identifier) để giữ 12 bit đầu tiên, cho phép tạo nên trục lớn hơn giữa các ATM switch
chung

Những trường header của tế bào ATM

Ngoài các trường GFC và VPI, còn có các trườg khác được sử dụng trong phần
header của tế bào ATM. Phần mô tả ngắn gọn sau về các trường header của tế bào ATM
minh hoạ trong hình 27-5.

Generic flow control (GFC)- Cung cấp những tính năng cục bộ để xác định
nhiều trạm chia sẻ một giao diện ATM riêng lẻ. Trường này có đặc trưng là không
được sử dụng và được thiết lập giá trị mặc định là 0 (nhị phân 0000)

Virtual Path Identifier (VPI)- Liên kết với VCI để xác định điểm đến kế tiếp
của một tế bào khi nó đi qua một loạt ATM switch trên đường đi đến đích.

Virtual Channel Identifier (VCI)- Liên kết với VPI để xác định điểm đến kế
tiếp của một tế bào khi nó đi qua một loạt ATM switch trên đường đi đến đích.

Payload type(PT)- Cho biết bit đầu tiên của tế bào chứa dữ liệu người dùng hay
ữ liệu điều khiển. Nếu tế bào chứa dữ liệu người dung thì bit được thiết lập là 0,
nếu chứa dữ liệu điều khiển thì bit được thiết lập là 1. Bit thứ hai cho biết có tắc
nghẽn hay không( 0-không tắc nghẽn, 1-tắc nghẽn) , và bit thứ ba cho biết tế bào
đã đi đến cuối của dãy tế bào và khung AAL5 đơn lẻ hay chưa (1 là tế bào cuối
cùng của khung)

Cell loss priority (CLP)- cho biết tế bào có nên được loại bỏ nếu nó bắt gặp tình
trạng tắc nghẽn cực độ khi nó di chuyển qua mạng. Nếu bit CLP bằng 1 thì tế bào
nên được loại bỏ để nhường chỗ cho những tế bào có bit CLP bằng 0.

Header error control (HEC)- Kiểm tra tất cả các lỗi chỉ trên 4 bit đầu tiên của
phần header. HEC có thể kiểm tra lỗi của từng bit trong những byte này, do đó tế
bào được duy trì tốt hơn việc loại bỏ nó.

II.3. MÔ HÌNH THAM CHIẾU CỦA ATM

Kiến trúc ATM sử dụng mô hình logic để mô tả chúc năng mà nó hổ trợ.Chức

năng của ATM tương tự với lớp physical và một phần của lớp datalink trong mô hình
OSI. Mô hình tham chiếu ATM được thiết kế thành những mức sau để làm cầu nối cho tất
cả các lớp:
Control- Mức này chịu trách nhiệm phát ra và quản lý những tín hiệu yêu cầu.
User- Mức này chịu trách nhiệm quản lý việc truyền dữ liệu.
Management- Mức chứa hai thành phần:
 - Lớp management quản lý chức năng đặc biệt của lớp, để dò tìm những tình trạng
không mong muốn và những vấn đề về giao thức.
- Mức management quản lý và phối hợp những chức năng lien quan tới toàn bộ hệ
thống.
Mô hình tham chiếu ATM được thiết kế thành những lớp sau:
Lớp Physical- Tương tự lớp physical của mô hình OSI, lớp physical của ATM
quản lý đường truyền phụ thuộc vào môi trường.

Lớp ATM- lớp ATM tương tự như lớp data link của mô hình OSI. Lớp ATM chịu
trách nhiệm chia sẻ đồng thời những mạch ảo trên một lien kết vật lý và đi qua
những tế bào thông qua mạng ATM. Để làm điều này nó sử dụng thông tin VPI và
VCI trong phần heađer của mỗi tế bào ATM.

ATM adaptation layer (AAL)- kết hợp với lớp ATM, AAL tương tự như lớp data
link của mô hình OSI. AAL chịu trách nhiệm phân tích những giao thức ở những
lớp cao hơn từ những chi tiết của tiến trình ATM. Lớp adaptation chuẩn bị dữ liệu
người dùng để chuyển đổi những tế bào và những phân đoạn dữ liệu vào trong 48
byte của trường payload.

Cuối cùng những lớp cao hơn ở trên AAL chấp nhận dữ liệu người dùng, sắp xếp nó vào
trong những gói và kiểm soát tới AAL.

Hình 27-7 mô tả mô hình tham chiếu ATM

The ATM Physical Layer

Lớp vật lý ATM có 4 chức năng:
 Những tế bào chuyển đổi vào trong một dòng bit,truyền và nhận những bit trên
môi trường vật lý được điều khiển ,những đường biên tế bào được kiểm tra,những tế bào
được đóng gói thích hợp với những kiểu của khung trong môi trường vật lý.

Lớp vật lý ATM được chia làm hai lớp con:PMD(physical medium dependent) và
TC(transmission convergence)
Lớp PMD cung cấp hai chức năng chính . Đầu tiên là truyền và nhận đồng bộ
bằng cách gởi và nhận một dòng bit liên tục với thông tin thời gian liên quan .Thứ hai là
chỉ rỏ phương tiện truyền vật lý cho môi trường vật lý đã sử dụng bao gồm những kiểu và
cáp kết nối.Ví dụ:Môi trường vật lý chuẩn cho ATM bao gồm
SDH/SONET(Synchoronous Digital Hierarchy/Synchoronous Optical Network),DS-3/Ẻ
,155 Mbps trên MMF(Multimode Fiber) sử dụng loại mã hoá 8B/10B và 155Mbps
8B/10B trên cáp STP(shielded twisted pair)
Lớp TC có 4 chức năng:mô tả tế bào,HEC(header error control) phát sinh và xác
minh 1 cách tuần tự,tách riêng tỷ lệ tế bào và khung truyền thích nghi. Chức năng mô tả
tế bào duy trì những đường biên tế bào ATM cho phép những thiết bị để định vị những tế
bào trong phạm vi 1 dòng của bit.sự phát sinh và xác minh 1 cách tuần tự của HEC kiểm
tra mã HEC để đảm bảo dữ liệu hợp lệ.Việc tách riêng tỷ lệ tế bào duy trì sự đồng bộ và
thêm vào hoặc loại bỏ những tế bào ATM để thích nghi với tỷ lệ tế bào ATM phù hợp tới
dung lương payload của hệ thống truyền.Bộ khung truyền đóng gói những tế bào ATM
vào trong những khung được chấp nhận để thi hành lớp vật lý riêng biệt

II.3.1. AAL1 (ATM ADAPTATION LAYERS 1)

AAL1 là một dịch vụ hướng kết nối, nó thích hợp để điều khiển tỉ lệ bit nguồn
không thay đổi (CBR). Như voice và video. ATM chuyển lưu lượng CBR đang sử dụng
những dich vụ mạch mô phỏng. Dịch vụ mạch mô phỏng cũng cung cấp phần đính kèm
của thiết bị hiện tại đang sử dụng những đường line cho thuê tới một mạng xương sống
ATM. AAL1 đòi hỏi thời gian đồng bộ giữa nguồn và đích. Vì lý do này AAL1 phụ thuộc
vào một môi trường như SONET, hỗ trợ xung clock.
Tiến trình của AAL1 chuẩn bị một tế bào truyền trong 3 bước. Đầu tiên, mô hình đồng bộ
mẫu (ví dụ 1 byte dữ liệu mẫu tốc độ truyền là 125 micro giây ) được đưa vào trường
payload. Bước hai những trường SN (sequence number) và SNP (sequence number
protection) được thêm vào để cung cấp thông tin mà AAL 1 nhận sử dụng để xác minh là
nó vừa nhận những tế bào đúng thứ tự. Bước 3, phần còn lại của trường payload được
điền đầy đủ với từng byte đơn lẻ để bằng 48byte .
Hình 27-8 minh hoạ cách AAL chuẩn bị truyền tế bào .
II.3.2. AAL2
Là loại lưu lượng khác có những thủ tục thời gian giống như CBR nhưng hướng
đến việc truyền trong tự nhiên. Nó được gọi là lưu lượng có tỉ lệ bit thay đổi (VBR). Đặc
trưng này bao gồm những dịch vụ được mô tả như việc đóng gói voice hoặc video không
có một tốc độ truyền dữ liệu cố định nhưng có những thủ tục tương tự những dịch vụ có tỉ
lệ bit là hằng số. AAL2 thì thích hợp cho lưu lượng VBR. Tiến trình AAL2 sử dụng 44
byte của tế bào payload cho dữ liệu người dùng và dự trữ 4 byte của trường payload để
hỗ trợ những tiến trình AAL2. Lưu lượng VBR được mô tả như thời gian thực (VBR-RT)
hoặc không có thời gian thực (VBR-VRT). AAL2 hỗ trợ cả hai loại lưu lượng VBR.

II.3.3. AAL3/4
AAL3/4 hỗ trợ cả dữ liệu hướng kết nối và dữ liệu không kết nối. Nó được thiết
kế cho những nhà cung cấp dịch vụ mạng và được sắp xếpmột cách kỹ lưỡng với SMDS
(switched multimegabit data service). AAL3/4 được sử dụng để truyền những gói SMDS
trên một mạng ATM.

AAL3/4 chuẩn bị một tế bào để truyền trong 4 bước. Bước đầu tiên, sự hội tụ các
lớp con (CS- convergence sublayer) tạo ra một giao thức đơn vị dữ liệu (PDU) bằng cách
chuyển một phần header có gắn thẻ bẳt đầu/kết thúc tới khung và nối thêm một trường
dài như một phần nối. Bước hai, việc phân đoạn và lắp ráp (SAR) những mảnh vỡ PDU
của lớp con và chuyển một header tới nó. Sau đó lớp con SAR nối thêm một CRC- 10
phần nối tới mỗi mỗi mảnh vỡ PDU để điều khiển lỗi. Cuối cùng, toàn bộ SAR PDU trở
thành trường payload của một tế bào ATM để lớp ATM chuyển phần header ATM chuẩn.
 Một header của AAL3/4 SAR PDU bao gồm các trường: type,sequence number
và multiplexing identifier. Trường type xác định một tế bào là sự bắt đầu,liên tục, hay kết
thúc của một thông điệp. Trường sequence number xác định thứ tự mà những tế bào nên
được lắp ráp. Trường Multiplexing identifier xác định những tế bào từ những nguồn lưu
thông khác nhau được chèn vàocùng mạch kết nối ảo (VCC) để những tế bào đúng đắn
được ráp lại ở đích.

II.3.4. AAL5
AAL5 là AAL chính cho dữ liệu và hỗ trợ cả dữ liệu hướng kết nối và không kết
nối. Nó được sử dụng để truyền hầu hết dữ liệu non-SMDS, như CLIP (classical ip over
ATM ) và LANE (LAN emulation ). AAL5 cũng được biết đến như là một lớp ứng dụng
đơn giản và hiệu quả (SEAL) bởi vì lớp con SAR chấp nhận một cách dễ dàng CS-PDU
và những phân đoạn nó vào trong 48-octet SAR-PDUs mà không dự trữ một vài byte
trong mỗi tế bào.
AAL5 chuẩn bị một tế bào để truyền qua 3 bước. Bước đầu tiên, lớp con CS nối
thêm vào một bộ đệm có chiều dài thay đổi và một phần nối 8 byte tới một khung. Bộ
đệm dùng để chắc chắn rằng kết quả PDU đưa ra trên đường biên 48 byte của một tế bào
ATM. Phần nối bao gồm chiều dài của khung và 32 bit CRC (cyclic redundancy check)
đã tính toán ở toàn bộ PDU bên kia. Điều này cho phép AAL5 nhận tiến trình để dò tìm
những bit có lỗi, những tế bào bị mất hoặc những tế bào mất thứ tự. Bước hai,lớp con
SAR phân đoạn CS-PDU vào những khối 48 byte. Một header và phần nối (trailer) không
được thêm vào (như trong AAL3/4), vì vậy những thông điệp không thể được chèn vào.
Cuối cùng, lớp ATM đặt mỗi khối vào trong trường payload của một tế bào ATM. Để tất
cả các tế bào loại ra cuối cùng, một bit trong trường payload type(PT) được thiết lập
thành 0 để đánh dấu tế bào đó không phải là tế bào cuối cùng trong dãy đại diện một
khung đơn lẻ. Để đánh dấu tế bào là cuối cùng, bit trong trường PT được thiết lập thành
1.

II.4. ĐỊA CHỈ CỦA ATM

Chuẩn ITU-T được dựa trên cơ sở sử dụng những địa chỉ E.164 (Tương tự như
những số điện thoại) cho những mạng ATM (B-ISDN) chung. Diễn đàn về ATM đã mở
rộng địa chỉ ATM bao gồm cả những mạng riêng. Nó được giải quyết trên mạng con hoặc
mô hình che phủ của địa chỉ mà trong đó lớp ATM chịu trách nhiệm ánh xạ những lớp địa
chỉ mạng tới những địa chỉ ATM. Mô hình mạng con này là một sự lựa chọn để sử dụng
giao thức lớp địa chỉ mạng (như là IP và IPX) và những giao thức định tuyến hiện tại
(như IGRP và RIP). Diễn đàn ATM đã định nghĩa một địa chỉ định dạng dựa trên cơ sở
cấu trúc của những địa chỉ dịch vụ mạng truy cập điểm (NSAP).

II.4.1. MÔ HÌNH ĐỊA CHỈ CỦA MẠNG CON

Mô hình địa chỉ của mạng con tách riêng lớp ATM từ một vài giao thức hiện tại ở
lớp cao hơn., như IP và IPX. Do đó, nó cần đến một lược đồ địa chỉ mới hoàn toàn và
giao thức định tuyến. Mỗi hệ thống ATM phải được gán một địa chỉ ATM , thêm vào một
vài giao thức địa chỉ lớp cao hơn. Điều này cần đến một giao thức phân giải địa chỉ ATM
(ATM ARP) để ánh xạ những địa chỉ lớp cao hơn tới những địa chỉ ATM tương ứng.
II.4.2. ĐỊNH DẠNG NSAP CỦA ĐỊA CHỈ ATM
20 byte NSAP- định dạng những địa chỉ ATM được thiết kế cho việc sử dụng
trong những mạng ATM riêng, trong khi đặc trưng của những mạng chung là sử dụng địa
chỉ E.164 là loại địa chỉ được định dạng và định nghĩa bởi ITU-T. Diễn đàn ATM đưa ra
lý thuyết rằng một NSAP mã hoá cho những địa chỉ E.164, nó được sử dụng để mã hoá
những địa chỉ E.164 trong phạm vi những mạng riêng, nhưng địa chỉ này cũng có thể
được sử dụng bởi một vài mạng riêng.
Những mạng riêng có thể dựa vào địa chỉ của chúng (định dạng NSAP) trên địa
chỉ E.164 của UNI chung để chúng được kết nối và có thể thêm vào đầu địa chỉ từ số
E.164, việc nhận ra vị trí những node bằng những bit có thứ tự thấp hơn. Tất cả NSAP-
định dạng địa chỉ ATM bao gồm 3 thành phần: AFI (authority and format identifier, IDI
(initial domain identifier) và DSP (Domain-specific part). AFI nhận dạng kiểu và định
dạng của IDI, IDI nhận dạng địa chỉ được phân chia và quản lý chứng thực. DSP chứa
thông tin định tuyến hiện tại.

Một cách khái quát :

13 byte đặc trưng cho tiền tố NSAP trả lời câu hỏi “Which switch?”.Mỗi switch
phải có một giá trị đầu tiên để nhận dạng nó.Thiết bị đính kèm tới switch thừa kế giá trị
tiền tố từ switch như phân đoạn của địa chỉ NSAP.Tiền tố được switch sử dụng để hổ trợ
cho việc định tuyến ATM.
6 byte tiếp theo, gọi là End Station Identifier (ESI), định danh phần tử gắn với
switch .Mổi một thiết bị gán tới switch cần phải có một giá tri duy nhất là ESI.
Byte cuối cùng ,gọi là byte Selecto(SEL), định danh dùng trong phạm vi quy
trình của thiết bị có kết nối đến đích.
Ba định dạng trên của địa chỉ ATM riêng có tính chất khác với AFI và IDI.Trong
NSAP-encoded E.164 format ,IDI là một số E.164.Trong định dạng IDI là dữ liệu mật
mã quốc gia(DCC),với những định dạng chi tiết của nhiều quốc gia .Như vậy những địa
chỉ được quản lý bởi ISO National Member Body trong mổi quốc gia..Trong phần định
dạng ICD ,IDI chỉ rõ một mã quốc tế (ICD-International Code Designator).
Mã ICD nhận dạng tổ chức quốc tê.
ATM Forum giới thiệu tổ chức hay dịch vụ cung cấp mạng riêng sử dụng cách
DCC hay ICD để làm biểu mẫu cho sơ đồ số.
Hình 27-9 minh hoạ cho ba dạng địa chỉ ATM sử dụng trong mạng riêng
II.4.3. CÁC TRƯỜNG ĐỊA CHỈ CỦA ATM
Những phần mô tả sau tóm tắt những trường đã được minh hoạ trong hình 27-9:
. AFI- Xác định kiểu và định dạng của địa chỉ (E.164,ICD, hoặc DCC)
. DDC- Xác định những quốc gia riêng biệt
. High-order Domain-Specific part(HO-DSP) - Kết hợp miền định tuyến (RD)
và vùng tự định danh (AREA) và những địa chỉ NSAP. Nhóm ATM kết hợp
những trường này để hỗ trợ một hệ địa chỉ đẳng cấp linh hoạt, nhiều cấp cho
những giao thức định tuyến tiền đề cơ bản.
. End System Identifier (ESI)- chỉ rõ địa chỉ MAC gồm 48 bit, được quản lý bởi
IEEE (Institute of Electrical and Electronic Engineers)
. Selector (SEL)- được sử dụng cho những thành phần cục bộ trong phạm vi
những trạm cuối và không quan trọng trong mạng.
. ICD- xác định những tổ chức riêng biệt trên thế giới.
. E.164- Cho biết địa chỉ BISDN E.164

II.4.4. KẾT NỐI ATM

Point-to-point kết nối hai hệ thống cuối ATM và có thể theo một hướng duy nhất (
truyền thông one-way) hoặc hai chiều (truyền thông two-way). Point-to-multipoint kết
nối một nguồn hệ thống cuối riêng lẻ(được hiểu như là node gốc) tới nhiều đích hệ thống
cuối (được hiểu như là leaves). Những kết nối như vậy chỉ theo một hướng duy nhất.
Những node gốc có thể truyền tới leaves, nhưng leaves không thể truyền tới gốc hoặc nơi
khác trên cùng một kết nối. Mô hình tế bào được xây dựng trong phạm vi mạng ATM
bằng những ATM switch nơi mà kết nối tách ra thành hai hoặc nhiều nhánh. Nó có thể là
sự mong muốn trong những mạng ATM để có những kết nối multipoint-to-multipoint hai
chiều. Những kết nối này thì tương tự như khả năng broadcast hoặc multicast của phương
tiện được chia sẻ trong những mạng LAN,như là Ethernet và Token Ring. Khả năng
broadcast thì dễ dàng thực thi với phương tiện được chia sẻ trong mạng LAN,nơi mà tất
cả những node trên một segment riêng lẻ phải xử lý tất cả những gói đã gửi trên segment
đó. Không may, một khả năng multipoint-to-multipoint không thể được thực thi bằng
việc sử dụng AAL5 là chuẩn AAL chung nhất để truyền dữ liệu qua một mạng ATM.
Không như AAL3/4,với trường MID (message Identifier), AAL5 không cung cấp một
hướng trong phạm vi tế bào của nó định dạng xen kẽ những tế bào từ những gói AAL5
khác trên một kết nối riêng lẻ. Điều này có nghĩa tất cả những gói AAL5 gửi tới một đích
đặc biệt qua một kết nối riêng biệt phải được nhận trình tự. Về mặt khác, tiến trình lắp ráp
lại ở đích sẽ không thể khôi phục lại những packet. Đó là lý do tại sao những kết nối
AAL5 point-to-multipoint chỉ có thể theo một chiều. Nếu một leaf node truyền một
packet AAL5 về phía kết nối, ví dụ, nó sẽ có thể nhận bằng cả node gốc và tất cả những
leaf node khác. Tại những node này,packet gửi bằng leaf có thể được chèn vào với những
gói đã gửi bằng gốc và có thể là những leaf node khác, ngăn cản việc lắp ráp của một vài
packet đã được chèn vào.

II.5. THIẾT LẬP TÍN HIỆU VÀ KẾT NỐI ATM

Khi một thiết bị ATM muốn điều chỉnh một kết nối với một thiết bị ATM khác, nó
gửi một gói tín hiệu yêu cầu kết nối lập tức tới ATM switch. Yêu cầu này chứa địa chỉ
ATM của ATM endpoint, cũng giống như một cài tham số QoS phụ thuộc vào kết nối.
Những giao thức tín hiệu ATM thay đổi bởi loại kết nối ATM, có thể là tín hiệu UNI hoặc
tín hiệu NNI. UNI được sử dụng giữa một hệ thống cuối ATM và ATM switch từ bên
ATM UNI và NNI đuợc sử dụng từ những kết nối NNI.
Diễn đàn về ATM chỉ rõ UNI 3.1 là chuẩn hiện tại cho tín hiệu UNI. UNI 3.1 dựa trên cơ
sở giao thức tín hiệu mạng chung Q.2931 dã phát triển bởi ITU-T. Những tín hiệu yêu
cầu UNI được truyền đi trong một kết nối mặc định đã được nhiều người biết đến.
VPI = 0, VPI = 5.

II.5.1. TIẾN TRÌNH THIẾT LẬP KẾT NỐI ATM

Tín hiệu ATM sử dụng phương pháp thiết lập kết nối one-pass là phương pháp
được sử dụng trong tất cả modem những mạng viễn thông như mạng điện thoại. Một thiết
lập kết nối ATM bắt đầu theo cách sau. Đầu tiên, từ nguồn hệ thống cuối gửi một tín hiệu
yêu cầu kết nối.Yêu cầu kết nối được truyền bá qua mạng. Kết quả là những kết nối được
thiết lập từ đầu đến cuối mạng. Yêu cầu kết nối truyền tới tận đích cuối cùng và yêu cầu
kết nối sẽ được chấp nhận hay bị từ chối.

II.5.2. Đ ỊNH TUYẾN VÀ ĐIỀU CHỈNH YÊU CẦU KẾT NỐI

Định tuyến yêu cầu kết nối bị chi phối bởi một giao thức đinh tuyến ATM ( mạng
riêng, giao diện mạng [PPNI-private network-network interface] định tuyến những kết
nối cơ bản trên những địa chỉ nguồn và đích), lưu lượng và những tham số chất lượng
dịch vụ vụ (QoS) yêu cầu bằng nguồn hệ thống cuối. Việc thương lượng yêu cầu kết nối
bị loại bỏ bởi đích đến được cho phép bởi vì việc định tuyến được căn cứ trên những
thông số kêt nối ban đầu. Việc thay đổi nhữnh tham số có thể ảnh hưởng đến việc định
tuyến kết nối.

Hình 27-10 : Những thiết bị thiết lập kết nối ATM thông qua phương pháp one-pass

CHƯƠNG III: IP OVER ATM

III.1. GIỚI THIỆU
III.1.1. THÁCH THỨC ĐỐI VỚI IP OVER ATM
Sự thành công của ATM(Asynchronous Transfer Mode) không đúng sự thật trong
khả năng truyền tải dữ liệu qua mạng truyền , phần lớn IP , trên khắp các bộ phận của
mạng . Điều phức tạp chính là IP hoạt động bên trong ATM bắt nguồn từ hai chuyên đề
khác nhau giữa chúng là hướng kết nối và không kết nối.
ATM là có hướng kết nối ,một kết nối cần được thiết lập giữa hai bên trước khi
truyền dữ liệu với nhau.Trước tiên kết nối được thiết lập , tất cả dữ liệu giữa chúng được
gởi từ bên này sang bên kia đường dẫn. Điều trái lại , IP không cần có kết nối và mổi một
gói IP đi đến một địa điểm khác bằng cách sử dụng bộ định tuyến độc lập trên từng bước
truyền cơ sở. Khi chúng ta cần truyền bằng IP trên mạng truyền thông ATM thì chúng ta
sẽ có hai chọn lựa.Một trong hai cách chọn lựa kết nối mới được thiết lập có yêu cầu giữa
hai bên hoặc dữ liệu truyền qua một kết nối có cấu hình trước hay nhiều hơn một kết nối
có cấu hình trước. Cách đầu tiên , khi một khối lượng dữ liệu được truyền đi là bé ,cước
phí chi trả cho việc thiết lập sẻ đắt và khả năng không thành công là không hợp lý.
Phương pháp tiếp cận thứ hai trước khi cấu hình đường dẫn có thể không phải là một
đường dẫn tối ưu và có thể lấn át bởi số lượng lớn dữ liệu đang được truyền.
QoS là một khái niệm quan trong trong mạng ATM. Nó gồm có các tham số
giống như bandwidth và yêu cầu về độ trễ của kết nối .Những yêu cầu đó bao gồm cả
thông điệp báo hiệu sử dụng để thiết lập cho một kết nối .Hiện tại IP(IPv4) có ý niệm
chung cho mổi một gói là điều cố gắng tốt nhất về cơ bản bằng bộ định tuyến. Để có điều
thuận lợi cho những đảm bảo QoS thuộc mạng ATM ,giao thức IP cần thay đổi kể cả
thông tin.

III.1.2. NHỮNG MÔ HÌNH CỦA IP OVER ATM

l
Mô hình mạng ngang hang.
Để thi hành IP trên những mạng ATM , chúng ta cần tìm hiểu điều liên quan của
những lớp giao thức ATM đến những lớp giao thức TCP/IP .Hai mô hình , một gọi là mô
hình ngang hang và mô hình kia là chồng mô hình hay chồng kiểu , được đưa ra.
Mô hình ngang hàng được chú ý đến trong lớp ATM ,một mạng ngang hang giống
như IP và dự định sử dụng chung lượt đồ địa chỉ với IP, gắn ATM cho những hệ thống ở
cuối cùng . ATM báo hiệu những yêu cầu gồm có địa chỉ IP và những switch trung gian
sẽ được route sử dụng những giao thức định tuyến sẵn có giống như OSPF. Những lượt
đồ không được chấp nhận bởi vì mặc dù nó đơn giản lượt đồ địa chỉ cho hệ thống cuối
cùng , nó làm phức tạp mục đích của những ATM switch bởi chúng có những chức năng
của một IP router. Hơn nửa , nếu mạng ATM ngoài những hổ trợ của giao thức lớp mạng
giống như IPX hay Appletalk, switch có biết được tất cả các giao thức định tuyến của nó.
Mô hình lồng nhau , đó là được nhận cuối cùng, tổng quan ATM giống như giao
thức ở lớp data link mà IP thi hành trên nó. Mô hình lồng nhau trong mạng ATM sẽ có
lượt đồ địa chỉ của riêng nó và giao thức định tuyến. Không gian địa chỉ mạng ATM thì
không có sự kết hợp hợp lý với không gian địa chỉ IP và ở đó sẽ ánh xạ giữa hai mô hình
đó. Mổi hệ thống cuối cùng sẻ có một địa chỉ ATM đặc trưng và không có liên quan nhiều
tới địa chỉ IP.
Từ đó nhu cầu ánh xạ giữa hai địa chỉ , một cách duy nhất để hiểu một trong
nhiều giao thức phân giải địa chỉ. Với mô hình lồng nhau ,về cơ bản có hai cách để chạy
IP trên ATM. Với mô hình bao phủ, có hai cách cơ bản để chạy IP over ATM. Một là xem
ATM như một mạng LAN và nhiều phần của mạng ATM trong những mạng con logic
gồm có những hệ thống cuối với cùng prefix IP.

Điều này gọi là Classical IP over ATM. Trong Classical IP over ATM , những hệ
thống cuối có mạng con hợp lý truyền thông với nhau thông qua các kết nối điểm cuối
ATM ,và giống trong mạng LAN, ARP servers sử dụng mạng con hợp lý để giải quyết
những địa chỉ IP vào trong địa chỉ ATM. Tuy nhiên lưu lượng giữa các hệ thống cuối
trong những mạng con phù hợp thì khác nhau có thể đi thông qua một router một cách
thản nhiên đính kèm cùng mạng ATM. Đây là điều không mong muốn khi router khởi đầu
một góc trễ cao và trở thành tình trạng thắt cổ chai băng thông.
Next Hop Resolution Protocol(NHRP) giải thích các bước ở vấn đề này.Hoạt
động trong từng phần riêng trong mạng ATM của các mạng con hợp lý, nó cho phép một
hệ thống cuối cùng trong mạng con giải quyết địa chỉ ATM(từ địa chỉ IP) của hệ thống
cuối trong mạng con hợp lý khác và thiết lập một kết nối các điểm cuối,gọi là đường cắt
giữa chúng.
Các phương pháp khác sử dụng mạng ATM giả dạng phổ cập giao thức mạng
LAN giống như Ethernet hay token ring. IP chạy trên nó có cùng một cách chạy của
Ethernet hay token ring. Đây gọi là mô hình mạng LAN(LANE).LANE cho phép những
ứng dụng tạm thời của IP chạy trên mạng ATM mà không cần có thay đổi nào.
Đó sẽ giúp tăng tốc độ của các mạng ATM. Tuy nhiên, giống như trong Classical
IP over ATM, khác nhau giữa các lưu lượng tranh đua trong các mạng LAN vẩn cần di
chuyển thông qua router . Giống truyền thông giữa LANE và NHRP, Multiprotocol Over
ATM(MPOA) giải quyết vấn đề bằng cách tạo đường tắt đó là đương rẽ giữa các router
và ELANs
 PAR và I-PNNI
Với phương pháp cao hơn , ATM và IP chạy mổi một giao thức riêng biệt. So với
ATM là PNNI và còn IP là OSPF. Với IP , những router không có khái niệm về cấu trúc
bên trong của mạng ATM, những switch không phân biệt giữa một ATM-attched router và
một ATM ở hệ thống cuổi.
Đôi khi nó cần cho việc các router biết được các giao thức định tuyến của ATM để
hiểu thiết lập trong các kết nối ATM cuối và cuối với các router khác. Kết quả này trong
PNNI augmented routing(PAR), với router ATM-attached phải chạy giống như ATM
switch và trao đổi cấu trúc và thông tin có thể đọc được với các switch và các router
khác.
Một phương pháp khác ,gọi là tích hợp PNNI(I-PNNI), dự định sử dụng của
PNNI như một giao thức đơn lẽ sử dụng trong tương lai trong mạng của các switch và
router

III.2. CLIP (CLASSICAL IP OVER ATM)

Giới thiệu

Bộ nhớ được định nghĩa là một ứng dụng đầu tiên của Classcal IP và ARP trong
một môi trường hình thể mạng ATM như là LIS (Logical IP Subnetwork) được mô tả
trong đoạn 3. Bộ nhớ này không làm cho sự tiến triển tiếp theo xảy ra của công nghệ
ATM vào một phạm vi khác như LIS,một cách cụ thể một mạng ATM riêng lẽ phát triễn
thay thế cho một vài phân đoạn Ethernet Local LAN và những mạng đó trở thành kết nối
tổng thể, ứng dụng của IP và ARP sẽ được xem là khác biệt. Bộ nhớ này dung duy nhất
cho ứng dụng của ATM giống như sự thay thế trực tiếp cho WIRES và phân đoạn Local
LAN kết nối IP ở trạm cuối và các router hoạt động trong mô hình Classical LAN-based .

I. Ứng dụng của IP và ARP sẽ là khác nhau. Điều này như ứng dụng của ATM
giống sự thay thế trực tiếp cho “wires” và phân đoạn mạng LAN kết nối IP ở
trạm cuối và hoạt động của router trong mô hình “classical”LAN-based
.Những vấn đề được tăng thêm do cầu nối MAC level và mô hình LAN là
vượt ngoài giới hạn phạm vi của bài thuyết trình này.
{{{

This memo introduces general ATM technology and nomenclature.

Readers are encouraged to review the ATM Forum and ITU-TS (formerly
CCITT) references for more detailed information about ATM
implementation agreements and standards.}}}

Acknowledgments
Lời báo nhận
Memo này không thể tiến về bên trong mà không
This memo could not have come into being without the critical review
from Jim Forster of Cisco Systems, Drew Perkins of FORE Systems, and
Bryan Lyles, Steve Deering, and Berry Kercheval of XEROX PARC. The
concepts and models presented in [1], written by Dave Piscitello and
Joseph Lawrence, laid the structural groundwork for this work. ARP
[3] written by Dave Plummer and Inverse ARP [12] written by Terry
 Bradley and Caralyn Brown are the foundation of ATMARP presented in
this memo. This document could have not been completed without the
expertise of the IP over ATM Working Group of the IETF and the ad hoc
PVC committee at the Amsterdam IETF meeting.

Laubach [Page 1]

RFC 1577 Classical IP and ARP over ATM January 1993

RFC 1557 Classical IP and ARP over ATM

I.Giới thiệu
Mục tiêu của việc đặc tả này là tương thích cho phép và bổ xung hoạt động bên
trong cho việc truyền phát các IP datagrams và yêu cầu ATM ARP và trả lời bằng ATM
Adaptation Layer 5(AAL5)
Chú ý: memo này định nghĩa duy nhất hoạt động của IP và phân giải địa chỉ
bằng ATM, và không có nghĩa là miêu tả hoạt động của mạng ATM. Nhiều tham chiếu
đến kết nối ảo ,thường xuyên là kết nối ảo, hay chuyển mạch kết nối ảo áp dụng duy nhất
trên các kênh kết nối sử dụng sự hổ trợ của IP và phân giải địa chỉ trên ATM.Vị trí memo
này không hạn chế hay có thủ tục nào trên kết nối ảo sủ dụng cho các chủ ý khác.
Khai triển ban đầu của ATM cung cấp một thay thê một phân đoạn LAN :
1.Mạng cục bộ (e.g, Ethernets, Token Rings và FDDI)
2.Các vị trí xương sống tồn tại giữa các mạng LAN.
3.Các mạch chuyên dụng hay bộ tiếp sóng khung PVCs giữa IP router.
Chú ý:
Trong 1 , IP router cục bộ với một hay nhiều hơn một giao diện ATM sẽ cho phép các kết
nối cô lập của các mạng ATM.
Trong 3, mạng ATM diện rộng chung và riêng sẽ sử dụng kết nối tới IP router , mà lần
lược có thể hay không có thể kết nối tới những mạng ATM cục bộ.ATM WANs và LANs
có thể tương kết. Mạng ATM riêng (cục bộ hay diện rộng ) sẽ sử dụng lý thuyết cấu trúc
địa chỉ ATM trong đặc tả ATM Forum UNI .
Cấu trúc này là mô hình sau định dạng của một mạng OSI Service Access Point
Address. Một địa chỉ ATM riêng duy nhất nhận ra một ATM điểm cuối. Mạng chung sẽ
sử dụng cấu trúc địa chỉ này hay địa chỉ kia trong ITU-TS giới thiệu ở E.164 hay cấu trúc
địa chỉ mạng riêng ATM .Một địa chỉ E.164 duy nhất nhận ra một giao diện tới một mạng
chung.
Nét đặc trưng và những đặc tính của các mạng ATM là khác nhau được tìm thấy
trong LANs:
ATM cung cấp một kết nối ảo trong môi trường switched. Thiết lập kết nối ảo
có lẽ làm trên PVC(Permanent Virtual Connection) hay SVC(Switched Virtual
Connection) động. SVC hướng tới quản lý các tín hiệu là chuyển đổi thi hành qua giao
thức Q.93B.
Dữ liệu chuyền qua kết nối ảo vào trong phân đoạn có khối lượng tế bào là 53
octet (5 octet là của ATM header và 48 octet còn lại là dữ liệu)
Chức năng của đơn vị ánh xạ sử dụng PDUs(Protocol Data Units) vào trong
trường thông tin của tế bào ATM và ngược lại là chuyển đổi trong AAL(ATM Adaptation
Layer).Khi một kết nối ảo được tạo ra một loại AAL cụ thể là kết hợp với kết nối ảo. Đó
là bốn loại khác nhau , đó là các phần riêng lẽ như AAL1,AAL2,AAL3,AAL4 và AAL5.
Loại AAL được biết do kết nối ảo qua điểm cuối qua việc gọi cơ chế cài đặt và không
mang bên trong đầu tế bào ATM. Đối với PVCs loại AAL được cấu hình quản lý tại điểm
cuối khi một kết nối được thiết lập. Đối với SVCs,loại AAL truyền thông dọc theo
đường dẩn của kết nối ảo qua Q.93B của thiết lập cài đặt và các điểm cuối sử dụng thông
tin tín hiệu cho việc cấu hình.Thông thường ATM switches không quan tâm đến loại AAL
của VCs. Định dạng AAL chỉ rõ một gói định dạng với kích thước lớn nhất (64K - 1)của
octet của dữ liệu người dùng.
Các ô cho một AAL5, PDU sẽ chuyển đổi từ đầu đến cuối,tế bào cuối cùng là phần tử
cuối của PDU. Chuẩn ATM bảo đảm trên một kết nối ảo ,các ô được duy trì thứ tự điểm
cuối đến điểm cuối.
Chú ý: AAL5 cung cấp dịch vụ chuyển giao dữ liệu không chắc chắn, nó lên tới giao thức
ở mức cao hơn để cung cấp sự phát lại.
Tín hiệu ATM Forum định nghĩa thiết lập kết nối điểm-điểm và điểm - nhiều
điểm.
{{{Multipoint-to-multipoint VCs
are not yet specified by ITU-TS or ATM Forum.}}}
Một địa chỉ ATM Forum ,ATM điểm cuối là mã hoá sang địa chỉ NSAP hay là
địa chỉ E.164 Public-UNI. Trong một số lựa chọn , cả hai bao gồm là địa chỉ ATM điểm
cuối và E.164 Public-UNI là cần bới một ATMARP client đến một phạm vi máy chủ khác
hay router Laubach. Từ đó sử dụng một địa chỉ ATM điểm cuối và địa chỉ E.164 Public
UNI do ATMARP là tương tự đến việc sử dụng một địa chỉ Ethernet, khái niệm của địa
chỉ phần cứng là mở rộng bao gồm địa chỉ ATM trong ngữ cảnh của ATMARP,mặc dù địa
chỉ ATM không cần có sự đáng kể của phần cứng .ATM Forum NSAPAs sử dụng cùng
định dạng cơ bản như U.S.GOSIP NSAPAs.
Chú ý: Địa chỉ ATM Forum không nên giải thích sự xuất hiện của U.S GOSIP
NSAPAs.Chúng không,người quản tri là khác nhau,với các trường được loại ra là khác
nhau,vâng vâng….
Những memo này diển tả khai triển ban đầu của ATM trong giới hạn của mạng
IP classical như là một sự thay thế trực tiếp cho mạng nội bộ và cho các kết nối AP với
các router kết nối bên trong,hoặc bên trong hay giữa các vùng quản lý. Mô hình classical
ở đây nói đến cách xử lý của bộ điều hợp máy chủ ATM như một giao diện kết nối mạng
đến hoạt động chồng giao thức IP trong mô hình LAN-based.
Đặc trưng của mô hình classical:
o.Cùng kích thước đơn vị truyền là sử dụng cho tất cả các kết nối ảo trong một LIS.
o.Mặc định sự đóng gói LLC/SNAP của các gói tin IP.
o.Cấu trúc định tuyến IP end-to-end lưu lại cùng một lúc.
o. Địa chỉ IP phân giải thành địa chỉ ATM nhờ sử dụng một dịch vụ ATMARP trong
phạm vi của LIS-ATMARPs lưu trong phạm vi của LIS. Từ viễn cảnh của client, kiến
trúc ATMARP lưu lại đúng mô hình cơ bản ARP trong hiện tại trong mục 3.
o.Một IP con sử dụng cho nhiều máy chủ và router.Mổi một kết nối ảo trục tiếp đến hai
thành phần IP trong phạm vi của cùng một LIS.
Tương lai các memo sẽ mô tả hoạt đông của IP over ATM khi mạng ATM được
khai triển toàn cầu và kết nối bên trong. Khai triển của ATM vào trong Internet nội bộ là
mới bắt đầu và sẽ hoàn thành trong vài năm tới.Trong thời gian phần này bắt đầu của
ranh giới dưới các lý do sau đây:
 o.Những người quản tri và quản lý các mạng con IP sẽ hướng đến các bước đầu
tiên của cùng nhiều mô hình như họ đã khai triển hiện nay.
{{{ The mindset of the community will change slowly over time as
ATM increases its coverage and builds its credibility.}}}
o.Thực nghiệm chính sách quản lý đáng tin cậy trên sự bảo mật,truy cập , định
tuyến,và khả năng sàn lọc của cổng IP Internet: i.e., firewalls. ATM sẽ không cho phép
đến cổng sau trong phạm vi cơ cấu cho đến khi ATM hỗ trợ tính năng quản lý tốt hơn các
dịch vụ đang tồn tại và các dịch vụ đang dung
o.Các chuẩn chung của IP over ATM sẽ có được thời gian để hoàn thành và
triển khai.
Memo này xủ lý chi tiết của mô hình kinh điển của IP và ATMARP over ATM.
Memo này không

This memo details the treatment of the classical model of IP and

ATMARP over ATM. This memo does not preclude the subsequent treatment
of ATM networks within the IP framework as ATM becomes globally
deployed and interconnected; this will be the subject of future
documents. This memo does not address issues related to transparent
data link layer interoperability.

4. Định dạng gói tin

Thực thi MUST hổ trợ IEEE 802.2 LLC/SNAP đóng gói được mô tả trong mục 2.
Đóng gói LLC/SNAP là định dạng gói tin mặc định cho IP datagrams
Memo này nhận ra phương pháp đóng gói khác có thể được sử dụng ,tuy nhiên
,sự thiếu hiểu biết hay thoả thuận , đóng gói LLC/SNAP là mặc định.

This memo recognizes the future deployment of end-to-end signalling

within ATM that will allow negotiation of encapsulation method on a
per-VC basis. Signalling negotiations are beyond the scope of this
memo.

5.Kích thước MTU

Kích thước mặc định của MTU cho các thành phần hoạt động của IP trên mạng
ATM được cho là 9180 octet. LLC/SNAP header là 8 octet,vì vậy mặc định giao thức
ATM AAL5 có kích thước đơn vị dữ liệu là 9188 octet.Trong mạng con classical IP ,các
giá trị khác có thể được sử dụng nếu và chỉ nếu tất cả các thành phần trong LIS đã được
cấu hình mặc định để sử dụng giá tri không mặc định.

III.2.1. LOGICAL SUBNET

Fig. 1 Classical IP over ATM
Fig. 1 chỉ ra cấu trúc của Classical IP over ATM. Tên cho biết ,cấu trúc này xem như
mạng ATM giống với các số tách rời trong mạng con IP đã kết nối thông qua router .Như
IP cấp dưới gọi là một logical subnet(LIS).Một LIS có đặc tính theo RFC 1577:
Các hệ thống cuối trong một LIS chia sẽ các tiền tố IP giống nhau và địa chỉ bao
ngoài.Trong cách này LIS là giống rất nhiều so với IP của mạng con theo truyền thống
trên một mạng LAN phát rộng.Tuy nhiên ,các IP của mạng con theo truyền thống là cách
ly bởi một route trong khi các LIS vẩn kết nối trong thực tế với mạng ATM. Điều này giải
thích tại sao nó gọi là mạng cấp dưới hợp lý: thành viên đối với LIS được xác định bởi
cấu hình của phần mềm, không phải do phần mềm thiết lập. Ngoài ra còn có ngụ ý rằng
truyền thong bên trong không nhất thiết phải cần thông qua router .
Những hệ thống cuối truyền thông trong một LIS với một LIS khác thông qua kết
nối của các điểm cuối với nhau trong ATM.
Khi một hệ thống cuối A cần truyền thông với hệ thống B,với trong cùng một
LIS,nó cần thiết lập một kết nối với B trước .A sẽ có địa chỉ IP của B nhưng nó sẽ không
biết được địa chỉ ATM. Để giải quyết địa chỉ IP vào trong địa chỉ ATM,giống như trong
IP của mạng con trước đây mổi một LIS bao gồm một ARP server,gọi là ATMARP server.
Để gởi một gói truy vấn ARP đó là bao gồm địa chỉ IP của B đến ATMARP server và
server sẽ trả lời điều đó tới địa chỉ ATM của B.Một thiết lập kết nối với B thông qua báo
hiệu P-NNI .
Những hệ thống cuối trong các LIS truyền thông với một hệ thống khác thông qua
router.Giống như IP của mạng con trước đây,một router là thành phần của nhiều LIS và
tương lai IP sẽ truyền thông giữa chúng.Tiêu biểu, mỗi LIS bao gồm một router và tất cả
các gói IP đó là không được trù định từ trước đến một hệ thống cuối trong cùng một LIS
theo route. Nếu router trong cùng một LIS ở đích hệ thống cuối ,nó theo gói đến đích hệ
thống cuối sử dụng sự mô tả của lượt đồ(intra-LIS).Cách khác nó theo gói đến một router
khác để đến đích trên các bước cơ bản.Ví dụ,trong hình Fig.1,router i là thành viên của cả
LIS i và LIS I + 1(I = 1,2,3,…,n-1)
Sau đó một gói từ một hệ thống cuối trong LIS 1 đến một hệ thống cuối trong LIS
2 sẽ đi thông qua router 1,router 2 ,…,router n-1. Đây không phải là lệnh bởi vì router
tập hợp các gói IP lại và đưa vào một khối lượng độ trễ lớn.Vì nó có thể thực hiện được
để có kết nối trực tiếp giữa hai hệ thống cuối giống như chúng được gắn trong cùng một
mạng ATM,giống như theo các bước truyền dứt khoát sẽ không bị lãng phí về thời gian
và tài nguyên.NHRP quy định vấn đề này bằng cách cho phép chỉ định .
3. IP Subnetwork Configuration

In the LIS scenario, each separate administrative entity configures

its hosts and routers within a closed logical IP subnetwork. Each
LIS operates and communicates independently of other LISs on the same
ATM network. Hosts connected to ATM communicate directly to other
hosts within the same LIS. Communication to hosts outside of the
local LIS is provided via an IP router. This router is an ATM
Endpoint attached to the ATM network that is configured as a member
of one or more LISs. This configuration may result in a number of
disjoint LISs operating over the same ATM network. Hosts of differing
IP subnets MUST communicate via an intermediate IP router even though
it may be possible to open a direct VC between the two IP members
over the ATM network.

The requirements for IP members (hosts, routers) operating in an ATM

LIS configuration are:

o All members have the same IP network/subnet number and address

mask [8].

o All members within a LIS are directly connected to the ATM

network.

o All members outside of the LIS are accessed via a router.

o All members of a LIS MUST have a mechanism for resolving IP

addresses to ATM addresses via ATMARP (based on [3]) and vice
versa via InATMARP (based on [12]) when using SVCs. Refer to
Section 6 "Address Resolution" in this memo.

Laubach [Page 5]

RFC 1577 Classical IP and ARP over ATM January 1993

o All members of a LIS MUST have a mechanism for resolving VCs to

IP addresses via InATMARP (based on [12]) when using PVCs. Refer
to Section 6 "Address Resolution" in this memo.

o All members within a LIS MUST be able to communicate via ATM with
all other members in the same LIS; i.e., the virtual Connection
topology underlying the intercommunication among the members is
fully meshed.

The following list identifies a set of ATM specific parameters that

MUST be implemented in each IP station connected to the ATM network:

o ATM Hardware Address (atm$ha). The ATM address of the individual

IP station.
 o ATMARP Request Address (atm$arp-req). atm$arp-req is the ATM
address of an individual ATMARP server located within the LIS.
In an SVC environment, ATMARP requests are sent to this address
for the resolution of target protocol addresses to target ATM
addresses. That server MUST have authoritative responsibility
for resolving ATMARP requests of all IP members within the LIS.
Note: if the LIS is operating with PVCs only, then this parameter
may be set to null and the IP station is not required to send
ATMARP requests to the ATMARP server.

It is RECOMMENDED that routers providing LIS functionality over the

ATM network also support the ability to interconnect multiple LISs.
Routers that wish to provide interconnection of differing LISs MUST
be able to support multiple sets of these parameters (one set for
each connected LIS) and be able to associate each set of parameters
to a specific IP network/ subnet number. In addition, it is
RECOMMENDED that a router be able to provide this multiple LIS
support with a single physical ATM interface that may have one or
more individual ATM endpoint addresses. Note: this does not
necessarily mean different End System Identifiers (ESIs) when NSAPAs
are used. The last octet of an NSAPA is the NSAPA Selector (SEL)
field which can be used to differentiate up to 256 different LISs for
the same ESI. (Refer to Section 5.1.3.1, "Private Networks" in [9].)

III.2.2. ATMARP SERVER

Hoạt động và cấu hình của một ATMARP server trong LIS tương tự với một ARP
server trong mạng con IP trước đây.Một gói yêu cầu về ARP được gởi từ hệ thống cuối
đến ARP server để giải quyết địa chỉ ATM của địa chỉ IP.ATMARP server là một bảng
bao gồm cặp địa chỉ IP và địa chỉ ATM như sau:<IP Address,ATM Address>.Nếu một cặp
địa chỉ khớp nhau thì địa chỉ IP được xây dựng, tương ứng địa chỉ ATM trả về sẽ được
kiểm tra ở hệ thống cuối trong gói ARP_REPLY.Cách khác một gói ARP_NAK được trả
về. Bảng nhập liệu dùng để định cấu hình bằng tay hay nghiên cứu thông qua một đăng
ký của hệ thống cuối với ATMARP server. Phần mô tả chi tiết của LIS và ATMARP có
thể xây dựng trên RFC 1577.

RFC 1577
6. Address Resolution

Address resolution within an ATM logical IP subnet SHALL make use of

the ATM Address Resolution Protocol (ATMARP) (based on [3]) and the
Inverse ATM Address Resolution Protocol (InATMARP) (based on [12]) as
defined in this memo. ATMARP is the same protocol as the ARP
protocol presented in [3] with extensions needed to support ARP in a
unicast server ATM environment. InATMARP is the same protocol as the
original InARP protocol presented in [12] but applied to ATM
networks. All IP stations MUST support these protocols as updated
and extended in this memo. Use of these protocols differs depending
on whether PVCs or SVCs are used.

6.1 Permanent Virtual Connections

 An IP station MUST have a mechanism (eg. manual configuration) for
determining what PVCs it has, and in particular which PVCs are being
used with LLC/SNAP encapsulation. The details of the mechanism are
beyond the scope of this memo.

All IP members supporting PVCs are required to use the Inverse ATM
Address Resolution Protocol (InATMARP) (refer to [12]) on those VCs
using LLC/SNAP encapsulation. In a strict PVC environment, the
receiver SHALL infer the relevant VC from the VC on which the
InATMARP request (InARP_REQUEST) or response (InARP_REPLY) was
received. When the ATM source and/or target address is unknown, the
corresponding ATM address length in the InATMARP packet MUST be set
to zero (0) indicating a null length, otherwise the appropriate
address field should be filled in and the corresponding length set
appropriately. InATMARP packet format details are presented later in

Laubach [Page 7]

RFC 1577 Classical IP and ARP over ATM January 1993

this memo.

Directly from [12]: "When the requesting station receives the InARP
reply, it may complete the [ATM]ARP table entry and use the provided
address information. Note: as with [ATM]ARP, information learned via
In[ATM]ARP may be aged or invalidated under certain circumstances."
It is the responsibility of each IP station supporting PVCs to re-
validate [ATM]ARP table entries as part of the aging process. See
Section 6.5 on "ATMARP Table Aging".

6.2 Switched Virtual Connections

SVCs require support for ATMARP in the non-broadcast, non-multicast

environment that ATM networks currently provide. To meet this need a
single ATMARP Server MUST be located within the LIS. This server MUST
have authoritative responsibility for resolving the ATMARP requests
of all IP members within the LIS.

The server itself does not actively establish connections. It

depends on the clients in the LIS to initiate the ATMARP registration
procedure. An individual client connects to the ATMARP server using
a point-to-point VC. The server, upon the completion of an ATM
call/connection of a new VC specifying LLC/SNAP encapsulation, will
transmit an InATMARP request to determine the IP address of the
client. The InATMARP reply from the client contains the information
necessary for the ATMARP Server to build its ATMARP table cache. This
information is used to generate replies to the ATMARP requests it
receives.

The ATMARP Server mechanism requires that each client be

administratively configured with the ATM address of the ATMARP Server
atm$arp-req as defined earlier in this memo. There is to be one and
only one ATMARP Server operational per logical IP subnet. It is
 RECOMMENDED that the ATMARP Server also be an IP station. This
station MUST be administratively configured to operate and recognize
itself as the ATMARP Server for a LIS. The ATMARP Server MUST be
configured with an IP address for each logical IP subnet it is
serving to support InATMARP requests.

This memo recognizes that a single ATMARP Server is not as robust as

multiple servers which synchronize their databases correctly. This
document is defining the client-server interaction by using a simple,
single server approach as a reference model, and does not prohibit
more robust approaches which use the same client-server interface.

Laubach [Page 8]

RFC 1577 Classical IP and ARP over ATM January 1993

6.3 ATMARP Server Operational Requirements

The ATMARP server accepts ATM calls/connections from other ATM end
points. At call setup and if the VC supports LLC/SNAP encapsulation,
the ATMARP server will transmit to the originating ATM station an
InATMARP request (InARP_REQUEST) for each logical IP subnet the
server is configured to serve. After receiving an InATMARP reply
(InARP_REPLY), the server will examine the IP address and the ATM
address. The server will add (or update) the map entry and
timestamp into its ATMARP table. If the
InATMARP IP address duplicates a table entry IP address and the
InATMARP ATM address does not match the table entry ATM address and
there is an open VC associated with that table entry, the InATMARP
information is discarded and no modifications to the table are made.
ATMARP table entries persist until aged or invalidated. VC call tear
down does not remove ATMARP table entries.

The ATMARP server, upon receiving an ATMARP request (ARP_REQUEST),

will generate the corresponding ATMARP reply (ARP_REPLY) if it has an
entry in its ATMARP table. Otherwise it will generate a negative
ATMARP reply (ARP_NAK). The ARP_NAK response is an extension to the
ARMARP protocol and is used to improve the robustness of the ATMARP
server mechanism. With ARP_NAK, a client can determine the
difference between a catastrophic server failure and an ATMARP table
lookup failure. The ARP_NAK packet format is the same as the
received ARP_REQUEST packet format with the operation code set to
ARP_NAK, i.e., the ARP_REQUEST packet data is merely copied for
transmission with the ARP_REQUEST operation code reset to ARP_NAK.

Updating the ATMARP table information timeout, the short form: when
the server receives an ATMARP request over a VC, where the source IP
and ATM address match the association already in the ATMARP table and
the ATM address matches that associated with the VC, the server may
update the timeout on the source ATMARP table entry: i.e., if the
 client is sending ATMARP requests to the server over the same VC that
it used to register its ATMARP entry, the server should examine the
ATMARP requests and note that the client is still "alive" by updating
the timeout on the client's ATMARP table entry.

Adding robustness to the address resolution mechanism using ATMARP:

when the server receives an ARP_REQUEST over a VC, it examines the
source information. If there is no IP address associated with the VC
over which the ATMARP request was received and if the source IP
address is not associated with any other connection, then the server
will add the entry and timestamp into its
ATMARP table and associate the entry with this VC.

Laubach [Page 9]

RFC 1577 Classical IP and ARP over ATM January 1993

6.4 ATMARP Client Operational Requirements

The ATMARP client is responsible for contacting the ATMARP server to

register its own ATMARP information and to gain and refresh its own
ATMARP entry/information about other IP members. This means, as
noted above, that ATMARP clients MUST be configured with the ATM
address of the ATMARP server. ATMARP clients MUST:

1. Initiate the VC connection to the ATMARP server for

transmitting and receiving ATMARP and InATMARP packets.

2. Respond to ARP_REQUEST and InARP_REQUEST packets received on

any VC appropriately. (Refer to Section 7, "Protocol
Operation"
in [12].)

3. Generate and transmit ARP_REQUEST packets to the ATMARP server

and to process ARP_REPLY and ARP_NAK packets from the server
appropriately. ARP_REPLY packets should be used to
build/refresh its own client ATMARP table entries.

4. Generate and transmit InARP_REQUEST packets as needed and to

process InARP_REPLY packets appropriately. InARP_REPLY packets
should be used to build/refresh its own client ATMARP table
entries. (Refer to Section 7, "Protocol Operation" in [12].)

5. Provide an ATMARP table aging function to remove its own old

client ATMARP tables entries after a convenient period of time.

Note: if the client does not maintain an open VC to the server, the
client MUST refresh its ATMARP information with the server at least
once every 20 minutes. This is done by opening a VC to the server
and exchanging the initial InATMARP packets.

6.5 ATMARP Table Aging

 An ATMARP client or server MUST have knowledge of any open VCs it has
(permanent or switched), their association with an ATMARP table
entry, and in particular, which VCs support LLC/SNAP encapsulation.

Client ATMARP table entries are valid for a maximum time of 15

minutes.

Server ATMARP table entries are valid for a minimum time of 20

minutes.

Prior to aging an ATMARP table entry, an ATMARP server MUST generate

an InARP_REQUEST on any open VC associated with that entry. If an
InARP_REPLY is received, that table entry is updated and not deleted.

Laubach [Page 10]

RFC 1577 Classical IP and ARP over ATM January 1993

If there is no open VC associated with the table entry, the entry is

deleted.

When an ATMARP table entry ages, an ATMARP client MUST invalidate the
table entry. If there is no open VC associated with the invalidated
entry, that entry is deleted. In the case of an invalidated entry and
an open VC, the ATMARP client must revalidate the entry prior to
transmitting any non address resolution traffic on that VC. In the
case of a PVC, the client validates the entry by transmitting an
InARP_REQUEST and updating the entry on receipt of an InARP_REPLY. In
the case of an SVC, the client validates the entry by transmitting an
ARP_REQUEST to the ATMARP Server and updating the entry on receipt of
an ARP_REPLY. If a VC with an associated invalidated ATMARP table
entry is closed, that table entry is removed.

6.6 ATMARP and InATMARP Packet Format

Internet addresses are assigned independently of ATM addresses. Each

host implementation MUST know its own IP and ATM address(es) and MUST
respond to address resolution requests appropriately. IP members
MUST also use ATMARP and InATMARP to resolve IP addresses to ATM
addresses when needed.

The ATMARP and InATMARP protocols use the same hardware type
(ar$hrd), protocol type (ar$pro), and operation code (ar$op) data
formats as the ARP and InARP protocols [3,12]. The location of these
fields within the ATMARP packet are in the same byte position as
those in ARP and InARP packets. A unique hardware type value has
been assigned for ATMARP. In addition, ATMARP makes use of an
additional operation code for ARP_NAK. The remainder of the
ATMARP/InATMARP packet format is different than the ARP/InARP packet
format.

The ATMARP and InATMARP protocols have several fields that have the
following format and values:
 Data:
ar$hrd 16 bits Hardware type
ar$pro 16 bits Protocol type
ar$shtl 8 bits Type & length of source ATM number (q)
ar$sstl 8 bits Type & length of source ATM subaddress (r)
ar$op 16 bits Operation code (request, reply, or NAK)
ar$spln 8 bits Length of source protocol address (s)
ar$thtl 8 bits Type & length of target ATM number (x)
ar$tstl 8 bits Type & length of target ATM subaddress (y)
ar$tpln 8 bits Length of target protocol address (z)
ar$sha qoctets source ATM number
ar$ssa roctets source ATM subaddress

Laubach [Page 11]

RFC 1577 Classical IP and ARP over ATM January 1993

ar$spa soctets source protocol address

ar$tha xoctets target ATM number
ar$tsa yoctets target ATM subaddress
ar$tpa zoctets target protocol address

Where:

ar$hrd - assigned to ATM Forum address family and is

19 decimal (0x0013) [4].

ar$pro - see Assigned Numbers for protocol type number for

the protocol using ATMARP. (IP is 0x0800).

ar$op - The operation type value (decimal):

ARP_REQUEST = 1
ARP_REPLY = 2
InARP_REQUEST = 8
InARP_REPLY = 9
ARP_NAK = 10

ar$spln - length in octets of the source protocol address. For

IP ar$spln is 4.

ar$tpln - length in octets of the target protocol address. For

IP ar$tpln is 4.

ar$sha - source ATM number (E.164 or ATM Forum NSAPA)

ar$ssa - source ATM subaddress (ATM Forum NSAPA)

ar$spa - source protocol address

ar$tha - target ATM number (E.164 or ATM Forum NSAPA)

ar$tsa - target ATM subaddress (ATM Forum NSAPA)

 ar$tpa - target protocol address

Laubach [Page 12]

RFC 1577 Classical IP and ARP over ATM January 1993

The encoding of the 8-bit type and length value for ar$shtl,
ar$sstl, ar$thtl, and ar$tstl is as follows:

MSB 8 7 6 5 4 3 2 1 LSB
+-----+-----+-----+-----+-----+-----+-----+-----+
| 0 | 1/0 | Octet length of address |
+-----+-----+-----+-----+-----+-----+-----+-----+

Where:

bit.8 (reserved) = 0 (for future use)

bit.7 (type) = 0 ATM Forum NSAPA format

= 1 E.164 format

bit.6-1 (length) = 6 bit unsigned octet length of address

(MSB = bit.6, LSB = bit.1)

ATM addresses in Q.93B (as defined by the ATM Forum UNI 3.0
signalling specification [9]) include a "Calling Party Number
Information Element" and a "Calling Party Subaddress Information
Element". These Information Elements (IEs) SHOULD map to
ATMARP/InATMARP source ATM number and source ATM subaddress
respectively. Furthermore, ATM Forum defines a "Called Party Number
Information Element" and a "Called Party Subaddress Information
Element". These IEs map to ATMARP/InATMARP target ATM number and
target ATM subaddress respectively.

The ATM Forum defines three structures for the combined use of number
and subaddress [9]:

ATM Number ATM Subaddress

-------------- --------------
Structure 1 ATM Forum NSAPA null
Structure 2 E.164 null
Structure 3 E.164 ATM Forum NSAPA
 IP members MUST register their ATM endpoint address with their ATMARP
server using the ATM address structure appropriate for their ATM
network connection: i.e., LISs implemented over ATM LANs following
ATM Forum UNI 3.0 should register using Structure 1; LISs implemented
over an E.164 "public" ATM network should register using Structure 2.
A LIS implemented over a combination of ATM LANs and public ATM
networks may need to register using Structure 3. Implementations
based on this memo MUST support all three ATM address structures.

ATMARP and InATMARP requests and replies for ATM address structures 1
and 2 MUST indicate a null ATM subaddress; i.e., ar$sstl.type = 1 and

Laubach [Page 13]

RFC 1577 Classical IP and ARP over ATM January 1993

ar$sstl.length = 0 and ar$tstl.type = 1 and ar$tstl.length = 0. When

ar$sstl.length and ar$tstl.length =0, the ar$tsa and ar$ssa fields
are not present.

Note: the ATMARP packet format presented in this memo is general in

nature in that the ATM number and ATM subaddress fields SHOULD map
directly to the corresponding Q.93B fields used for ATM
call/connection setup signalling messages. The IP over ATM Working
Group expects ATM Forum NSAPA numbers (Structure 1) to predominate
over E.164 numbers (Structure 2) as ATM endpoint identifiers within
ATM LANs. The ATM Forum's VC Routing specification is not complete
at this time and therefore its impact on the operational use of ATM
Address Structure 3 is undefined. The ATM Forum will be defining this
relationship in the future. It is for this reason that IP members
need to support all three ATM address structures.

6.7 ATMARP/InATMARP Packet Encapsulation

ATMARP and InATMARP packets are to be encoded in AAL5 PDUs using

LLC/SNAP encapsulation. The format of the AAL5 CPCS-SDU payload field
for ATMARP/InATMARP PDUs is:

Payload Format for ATMARP/InATMARP PDUs:

+------------------------------+
| LLC 0xAA-AA-03 |
+------------------------------+
| OUI 0x00-00-00 |
+------------------------------+
| Ethertype 0x08-06 |
+------------------------------+
| |
| ATMARP/InATMARP Packet |
| |
+------------------------------+

The LLC value of 0xAA-AA-03 (3 octets) indicates the presence of a

SNAP header.
 The OUI value of 0x00-00-00 (3 octets) indicates that the following
two-bytes is an ethertype.

The Ethertype value of 0x08-06 (2 octets) indicates ARP [4].

The total size of the LLC/SNAP header is fixed at 8-octets. This

aligns the start of the ATMARP packet on a 64-bit boundary relative
to the start of the AAL5 CPCS-SDU.

Laubach [Page 14]

RFC 1577 Classical IP and ARP over ATM January 1993

The LLC/SNAP encapsulation for ATMARP/InATMARP presented here is

consistent with the treatment of multiprotocol encapsulation of IP
over ATM AAL5 as specified in [2] and in the format of ATMARP over
IEEE 802 networks as specified in [5].

Traditionally, address resolution requests are broadcast to all

directly connected IP members within a LIS. It is conceivable in the
future that larger scaled ATM networks may handle ATMARP requests to
destinations outside the originating LIS, perhaps even globally;
issues raised by ATMARP'ing outside the LIS or by a global ATMARP
mechanism are beyond the scope of this memo.

III.2.3. SỰ ĐÓNG GÓI DỮLI ỆU

Sự đóng gói dữ liệu cho IP over ATM theo lý thuyết trong RFC 1483. ALL 5 được sử
dụng để mang theo các gói IP ở các điểm cuối với điểm cuối. Hai mô hình đóng gói, mô
hình thứ nhất gọi là dồn VC Based và mô hình còn lại là sự đóng gói LLC,chúng được
xác định rõ. Điểm khác nhau giữa hai mô hình trên là sự cho phép của các giao thức cuối
cùng để mang đi trên môt VC đơn lẻ trong khi kết nối cũ tới giao thức VC based
multiplexing . Điểm khác nhau giữa hai mô hình trên cho phép đa giao thức thực hiện
trên một VC đơn lẻ trong khi kết nối trước đây là từ một VC đến một giao thức đơn lẻ.

VC Based Multiplexing
Với VC Based Multiplexing , VC là ranh giới tới giao thức cụ thể và đóng gói dữ
liệu trực tiếp vào trong trường CPCS-PDU của ALL 5 .Thế nên mổi một kết nối có thể
mang theo mổi một giao thức mà thôi. Phương pháp này tốt hơn trong khi một số lớn các
cách của VC có thể thiết lập nhanh và thận trọng hơn .

Đóng gói LLC

Với đóng gói LLC, một số giao thức (e.g , IP , IPX ,AppleTalk) có thể mang đi trên cùng
kết nối VC. Trong phương pháp này , một gói IP sẽ được thêm vào đầu của header IEEE
802.2 LLC trước khi nó đóng gói vào trong khung ALL 5.Phương pháp này tốt hơn khi
phương pháp tách rời VC để giao thức mang đi là đắt đỏ và không khả thi,e.g,mỗi một
kiểu kết nối được hổ trợ PVC hay cước tính căn bản trên số của phần VC.Nó sử dụng
phương pháp đóng gói mặc định cho tất cả các giao thức IP over ATM.

III.3. NHRP (NEXT HOP RESULATION PROTOCOL)

Như trước đây đã đề cập, với Classical IP over ATM, giao tiếp inter-LIS phải
thong qua router, đó không phải là giải pháp tối ưu khi cả hai phần liên quan được gắn
trong cùng một mạng ATM.
Kết nối trực tiếp giữa chúng được yêu cầu và trên thực tế nó không khó để đạt
được.Tất cả những gì chúng ta cần là một cơ chế cho hệ thống cuối để phân giải địa chỉ
IP của hệ thống cuối khác trong foreign LIS vào trong địa chỉ ATM tương ứng của nó.
NHRP giống như giao thức dùng để thực hiện nhiệm vụ này.NHRP bao gồm hai loại thực
thể : NHRP server(NHSs) và NHRP client(NHC),và những giao thức giữa chúng.Mổi
LIS chứa đụng ít nhất là một NHRP server và mổi hệ thống cuối là NHRP client . Khi
một hệ thống cuối cần phân giải một địa chỉ IP , nó gởi một yêu cầu đến NHRP server.
Một NHS có thể phục vụ nhiều hơn một LIS và nó giữ lại bảng chứa địa chỉ IP và
địa chỉ ATM cho tất cả các máy liên quan tới các LIS mà nó đang phục vụ.Nếu địa chỉ IP
được truy vấn liên quan đến những LIS này ,NHS đòi hỏi phải thấy một dòng trùng khớp
địa chỉ IP và trả lời lại với địa chỉ ATM tương ứng .Ngoài ra một phản hồi từ chối sẽ bị
trả lại.
Cho đến nay NHS được dùng chính xác như những ATMARP server,trên thực tế
trong các LIS nơi mà NHC và ATMARP client cùng tồn tại, NHSs là kết hợpvới chức
năng của ATMARP server .Tuy nhiên ,sự giới hạn của ATMARP server không thể phân
giải một địa chỉ IP liên quan tới một LIS khác trong khi một NHRP server thì có thể.Khi
một truy vấn đưa đến một NHRP server thì đối với một địa chỉ IP thuộc một LIS không
được thực hiện, nó sẽ quản lý việc chuyển truy vấn qua NHS phục vụ LIS . NHSs phục
vụ LIS trên mạng ATM được cấu hình trước những kết nối giữa chúng để tạo thành mạng
định tuyến cho các truy vấn NHRP .
Nhờ có các giao thức định tuyến như OSPF thực thi giữa những NHS, giống như
IP routers NHSs biết bước nhảy kế tiếp đi qua truy vấn NHRP để đi đến đúng nơi NHS.
Điều này cho biết chính xác đối với tên của NHRP sẽ đi đến từ đâu.

Khi NHS phục vụ LIS nhận truy vấn, nó sẽ trả lời với địa chỉ ATM tương ứng tới
hệ thống cuối bắt đầu truy vấn. Việc trả lời sẽ được chuyển lại thong qua NHSs và NHSs
trung gian có thể lưu lại dòng <IP address, ATM address> để những truy vấn NHRP sau
có cùng địa chỉ IP sẽ đuợc chặn lại và trả lời. Tính năng này đuợc dùng để lưu giữ nhiều
lưu lượng NHRP. Mỗi lần người gửi biết địa chỉ ATM của người nhận, nó có thể thiết lập
một kết nối end-to-end với người nhận, được gọi là đường tắt, để chuyển những gói IP
giữa chúng. Trước khi lối tắt được thiết lập, dữ liệu sẽ vẫn tiếp tục đi qua các router
giống như classical IP over ATM.

Fig. 2 NHRP
Fig.2 chỉ ra một mạng ATM phân chia thành ba LIS, mỗi cái được phục vụ bởi NHS.
Router 1 được kết nối tới cả hai LIS 1 và LIS 2, và router 2 đuợc kết nối tới cả hai LIS2
và LIS 3. Những hệ thống cuối A và B được gắn lần lượt vào LIS 1 và LIS 3.
Bây giờ A muốn gửi dữ liệu tới B:
Với classical IP over ATM thì dữ liệu phải di chuyển qua router1 và router2.
Với NHRP, A gửi một yêu cầu NHRP tới NHS1và tiếp tục tới NHS2 sau đó tới
NHS3. Khi NHS 3 đang phục vụ LIS3 chứa hệ thống cuối B, nó sẽ trả lời tới A với địa
chỉ ATM của B. Khi sự phản hồi chuyển trở lại, nó có thể đi qua NHS 2 và NHS 1. NHS
1 và NHS 2 sẽ lưu giữ thông tin này để những truy vấn NHRP sau này sẽ được trả lời trực
tiếp mà không phải chuyển nó tới NHS. Khi A nhận trược phản hồi nó sẽ thiết lập một kết
nối end-to-end với B để truyền dữ liệu giữa chúng.

III.4. IP MULTICAST OVER ATM

Classical IP over ATM và NHRP chỉ hổ trợ IP unicast over ATM. Để hổ trợ IP
multicast,hai vấn đề cần được giải quyết: đầu tiên chúng ta cần một giao thức phân giải
địa chỉ để chuyển một địa chỉ IP multicast vào trong một danh sách địa chỉ ATM,và điều
này được giải quyết bởi MARS ( Multicast Address Resolution Server).Thứ hai,chúng ta
cần phải chỉ rỏ làm thế nào dữ liệu multicast được truyền giữa các vùng liên quan , nhiều
mạng VC và Multicast Server (MCS) là hai giải pháp khả thi.

Một MARS ( Multicast Address Resolution Server) được giới thiệu trong mỗi LIS
để thực thi phân giải địa chỉ Multicast. Nó trả lời những truy vấn cho những địa chỉ
multicast từ những hệ thống cuối trong cùng một phương pháp như ATMARP server trả
lời những truy vấn cho những địa chỉ unicast.Một hệ thống cuối tham gia hoặc không
tham gia nhóm multicast riêng biệt bằng việc gởi những gói IGMP (Internet Group
Multicast Protocol ) đến MARS.
Khi một địa chỉ IP multicast được phân giải trong một danh sách của các điểm
cuối , dữ liệu cần được chuyển giữa các thành viên của nhóm từ người gỏi tới những
người nhận .Một cách để làm điều này là để mổi thành viên của nhóm cài đặt một kết nối
point-to-multipoint với tất cả những thành viên của nhóm khác và cách tiếp cận này gọi
là VC Mesh.
Một phương pháp khác được giới thiệu là MCS (Multicast Server) trong mổi LIS
để hổ trợ multicast. Khi một truy vấn của hệ thống cuối cho địa chỉ multicast , MARS sẽ
trả lời đến chúng với một địa chỉ ATM của MCS. Sau đó hệ thống cuối gởi những gói
multicast tới MCS . MCS sẽ xây dựng kết nối point-to-multipoint hay multipoint-to-point
tới những thành viên của nhóm để truyền những gói đã nhận từ hệ thống cuối để tất cả
các thành viên của nhóm theo lý thuyết trong trường địa chỉ của gói multicast. Với MCS,
nếu thành viên của một nhóm multicast thay đổi, nó chỉ cần sữa VC point-to-multipoint
tới những thành viên của nhóm trong khi với VC mesh, tất cả những kết nối trong mesh
này phải được thay đổi. Tuy nhiên, MCS cần lắp ghép lại những gói cellified đã gửi từ
nguồn và gửi lại chúng đến những thành viên của nhóm vì vậy nó có thể trở thành điểm
conjestion riêng biệt và giới thiệu chắc chắn số lương góc trễ. Với VC mesh việc lắp ráp
là không cần vì góc trễ được làm cực tiểu.

III.5. LAN EMULATION (LANE)

Trong LANE(LAN Emulation), một mạng ATM được cấu hình để tái tạo một
Ethernet hay Token Ring LAN . Kết quả LAN gọi là một ELAN(mô hình mô phỏng
mạng LAN) . LANE định nghĩa một giao diên của dịch vụ mà tìm một cách chính xác IP
giống như Ethernet hay Token Ring .Trong phương pháp này phần mềm IP sẽ chạy trước
trên Ethernet và Token Ring có thể chuyển trên mạng ATM mà không cần thay đổi . Sự
trợ giúp này làm nhanh hơn sự triển khai ATM như một cấu trúc mạng LAN.
LANE chỉ rỏ theo bốn kiểu thực thể sau và giao thức giữa chúng:
LEC(Lan Emulation Client):Một LEC chạy trên mổi hệ thống cuối ATM trong một
ELAN để tái tạo một Ethernet node hay Token ring node .Mỗi LEC có một hay nhiều
địa chỉ MAC liên quan đến nó. Nó liên hệ với LES để phân giải địa MAC thành địa chỉ
ATM và thực thi một cách chắc chắn chức năng điều khiển. Nó mô phỏng giao diện dịch
vụ Ethernet hay Token Ring để lớp IP bằng việc đóng gói các IP khi được gởi đi vào
trong những khung ELAN hay mở gói đi vào khung ELAN trong những gói IP.
LES (LAN Emulation Server ):Mổi một ELAN bao gồm một LES,chúng hoạt
động như một thiết bị phối hợp.Mổi một LEC sẽ đăng ký với LEC một cặp <MAC
address,ATM address>. Dựa vào thông tin LEC phân giải địa chỉ MAC thành địa chỉ
ATM tương ứng trong cùng một ATMARP server trong Classical IP over ATM.
BUS(Broadcast and Unknown Server): Mổi ELAN bao gồm một BUS để mô
phỏng khả năng chứa broadcast của Ethernet và Token Ring . Một LEC muốn quảng bá
một gói gởi tới BUS, chúng tiếp tục chuyển tới mổi thành viên trong ELAN một bản
copy. Trước khi dữ liệu kết nối trực tiếp được xây dụng giữa hai LEC ,dữ liệu giữa chúng
cũng được chuyển thông qua BUS.
 LECS (LAN Emulation Configuration Server ): Ở đó có thể nhiều hơn một ELAN
đang chạy trong mạng ATM . LECS giữ thông tin cấu hình của mổi ELAN bao gồm
LECs, LES và BUS .Hoạt động của LANE bao gồm bốn bước sau:
Cấu hình:trong bước này, một LEC liên hệ với LECS để biết mỗi ELAN nó phụ
thuộc vào địa chỉ LEC và BUS để tham gia vào ELAN. Có ba cách cho LEC truy cập vào
LECS. Đầu tiên nó cấu hình địa chỉ ATM của LECS vào LEC . Cách hai nó có gắn
VPI/VCI trực tiếp đến LECS từ mổi hệ thống cuối . Cách cuối cùng nhận nó thông qua
ILMI.
Đăng ký : Bây giờ để LEC hiểu địa chỉ ATM của LES của ELAN tham gia ,nó
gởi một thông điệp đăng ký tới LES bao gồm địa chỉ MAC và địa chỉ ATM của LEC.
Trong lúc nhận thông điệp này,LES sẽ ghi lại thông tin trong bảng phân giải địa chỉ của
nó và tạo ra một vài kết nối đến LEC cho việc truyền dữ liệu và điều khiển thông tin.
Kết nối BUS: sử dụng địa chỉ ATM của BUS đã đạt đuợc trong giai đoạn cấu hình
.Nó thiết lập một kết nối tới BUS để truyền dữ liệu Multicast .
Việc truyền dữ liệu: Đây là bước giao dịch chính của LANE. Khi một LEC muốn
gửi một vài dữ liệu tới một LEC khác, nó sẽ yêu cầu LES về địa chỉ ATM của LEC đó.
Với việc sử dụng địa chỉ đó nó sẽ thiết lập việc kết nối dữ liệu trực tiếp với LEC đó. Về
sau những khung Ethernet hay token ring giữa chúng được truyền trên kết nối này ở trong
những khung AAL5 với việc đóng gói LLC. Nếu một LEC cần quảng bá một gói, đơn
giản nó gửi một gói tới BUS và BUS này sẽ truyền tiếp tục đến mỗi thành viên của
ELAN một bản copy của gói đó. Mặc dù dữ liệu Intra-ELAN được truyền thông qua kết
nối dữ liệu trực tiếp giữa hai LEC. Các LEC phụ thuộc vào những ELAN khác nhau có
thể vẫn phải giao tiếp thông qua nhiều router. Những mô tả sau, MPOA giải quyết vấn đề
này bằng cách tạo ra các lối tắt giữa những ELAN.

LAN Emulation
LANE(Lan Emulation) là chuẩn được định nghĩa bởi ATM Forum đó đưa đến gán
vào trạm tiếp theo qua ATM có cùng tính năng đó chúng vẩn sử dụng bình thường từ sự
kế thừa LANs,ví dụ như Ethernet và Token Ring. Chức năng của giao thức LANE là một
mô phỏng đến LAN trên đỉnh của một mạng ATM.
Đặc trưng, giao thức LANE định nghĩa cơ cấu cho việc tranh đua giữa IEEE
802.3 hay một Token Ring LAN 802.5.Giao thức LANE hiện thời không định nghĩa một
sự đóng gói riêng biệt cho FDDI
Fast Ethernet(100Base T)và IEEE 802.12(100VG -AnyLAN) cả hai có thể ánh xạ
không đổi bởi vì chúng sử dụng cùng một định dạng gói.
Hình 27-11 so sánh một physical LAN và một ELAN
Figure 27-11 Nhiều mạng ATM Networks có thể cạnh tranh với một Physical LAN
 Giao thức LANE định nghĩa một giao diện dịch vụ cho các giao thức tầng cao hơn
để đồng nhất đến sự hiện hữu cũa LANs. Dữ liệu gởi qua mạng ATM sẽ được đóng gói
trong gói định dạng LAN MAC. Đặt đơn giản, các giao thức LANE làm cho một mạng
ATM chú ý và chạy giống như một Ethernet hay Token Ring LAN mặc dù hoạt động
nhanh hơn một Ethernet hiện tại hay một mạng Token Ring LAN
Thật quan trọng để chú ý rằng LANE không cố gắng vượt qua cạnh tranh với giao
thức MAC hiện thời của LAN đặc biệt được đề cập. LANE không cần sữa đổi đến các
giao thức tầng cao hơn để làm cho chúng hoạt động lên trên một mạng ATM.Bởi vì dịch
vụ LANE hiện tại có cùng giao diện dịch vụ của của giao thức MAC có sẵn đến các
đường dẩn của lớp mạng(như là một NDIS hay ODI giống như giao diện đường
dẩn),không thay đổi là quy định trong các đường dẩn.

Kiến trúc của giao thức LANE

Chức năng cơ bản của giao thức LANE là giải quyết địa chỉ MAC sang địa chỉ
ATM. Mục tiêu là giải quyết ánh xạ địa chỉ để các hệ thống cuối LANE có thể thiết lập
kết nối trực tiếp giữa chính chúng và tiếp đến là dữ liệu.Giao thức LANE khai triển trong
hai kiểu trang bị đính kèm ATM. Cạc mạng ATM hay NICs(ATM network interface card)
và liên mạng và trang bị chuyển mạch LAN.
ATMNICs thực thi giao thức LANE và giao diện đến mạng ATM trừ khi hiện hữu
giao diện dịch vụ LAN hiện thời đến các đường dẩn giao thức mức cao hơn trong phạm
vi gắn với hệ thống cuối. Giao thức lớp mạng trên hệ thống cuối duy trì truyền thông
giống như những cái ấy trên được biết trên LAN bằng sử dụng các thủ tục.Tuy nhiên,
chúng có khả năng để sử dụng bandwidth rộng lớn của các mạng ATM. Lớp thứ hai của
mạng phục vụ để thực thi LANE gồm có ở ATM-attached LAN switches và router.
Những dịch vụ này , củng như gắn trực tiếp đến các máy chủ ATM trang bị cạc ATM, sử
dụng để hổ trợ một dịch vụ ảo LAN trong các máy chủ trên các LAN switch gán độc lập
và riêng biệt đến VLANs của vị trí vật lý.
Hình 27-12 chỉ ra cấu trúc giao thức LANE thi hành trên dịch vụ mạng ATM
.
Chú ý: Giaothức LANE không ảnh hưởng trực tiếp đến các ATM switch.Như hầu hết các
giao thức liên mạng ATM khác,LANE xây dựng trên mô hình chồng. Thông thường,
trong suốt hoạt động của các giao thức LANE và các ATM switch, sử dụng những thủ tục
tín hiệu chuẩn ATM .

Các thành phần LANE

Giao thức LANE định nghĩa hoạt động của một LANE đơn lẻ hay là VLAN. Mặc
dù nhiều ELAN có thể tồn tại một lúc trên một mạng ATM riêng lẽ, và ELAN cạnh tranh
với Ethernet hay Token Ring và bao gồm các thành phần dưới đây:
LEC(Lan Emulation Client) _ LEC là một thực thể trong một hệ thống cuối để
chuyển đổi dữ liệu sang phân giải địa chỉ ,và đăng ký địa chỉ MAC với LES(LAN
Emulation Server), hơn nữa LEC hổ trợ một giao diện LAN chuẩn đển giao thức lớp cao
hơn trên sự kế thừa các LAN. Một ATM hệ thống cuối đó để kết nối tới nhiều ELAN có
một LEC cho mỗi ELAN.
LES (LAN Emulation Server) _LES hổ trợ một trung tâm điều khiển cho Less
đến đăng ký tiếp theo và điều khiển thông tin. Duy trì LES là một danh sách các địa chỉ
MAC trong ELAN và địa chỉ tương ứng NSAP.
BUS (Broadcast and Unknow Server) _BUS là đa server để sử dụng rất nhiều đến
lưu lượng các địa chỉ đích không biết và đa multicast và lưu lượng quảng bá đến phạm vị
máy khách bên trong một ELAN. Mổi một LEC là một tổ chức với duy nhất một BUS
cho mổi ELAN.
LECS(LAN Emulation Configuration Server)_LECS duy trì một cơ sở dữ liệu
của các LEC và các ELAN mà thuộc về chúng. Server này chấp nhận các yêu cầu từ các
LES và phản hồi lại với tên định danh ELAN thích hợp, địa chỉ ATM của LES phục vụ
thích hợp với ELAN. Một LECS cho mổi server quản lý miền tất cả phạm vi các ElAN
với tên miền đó. Bởi vì các thành phần server đơn lẽ không có dư thừa, Cisco có khắc
phục thiếu sót này bằng việc thực thi một giải pháp riêng gọi là SSRP(Simple Server
Redundancy Protocol). SSRP làm việc với một vài nhà cung cấp LEC, tuy nhiên,nó yêu
cầu sử dụng thiết bị là thành phần máy chủ là Cisco . Nó cho phép lên đến 16 LECS cho
mỗi mạng ATM LANE và nhiều vô kể cặp LES/BUS cho mỗi ELAN. Ngoài ra ATM
Forum đưa ra một phương pháp độc lập để hổ trợ server dư thừa là LNNI (Lane
Emulation Network-Network Interface). Vì thế , server từ những nhà cung cấp khác nhau
có thễ hỗ trợ hoạt đông dư thừa bên trong.
Hình 27-13 : Minh hoạ thành phần của một ELAN

Các loại kết nối LAN Emulation

Giai đoạn 1 các thực thể LANE truyền thông với thực thể khác bằng cách sử dụng
dịch vụ của các ATM VCC. Các LEC duy trì phân ra các kết nối để truyền dữ liệu và
điều khiển lưu lượng. Các kết nối dữ liệu LANE là dữ liệu trực tiếp VCC,multicast gởi
đến VCC, và multicast tiếp tới VCC. Dữ liệu trực tiếp VCC là thiết lập VCC theo hai
chiều điểm đến điểm giữa hai LEC mà muốn thay đổi dữ liệu. Hai đặc trưng của LEC sử
dụng cùng dữ liệu trực tiếp VCC để truyền tất cả các gói giữa chúng tối ưu hơn mở một
VCC mới cho mỗi một cặp địa chỉ MAC.
{{. This technique conserves connection resources and
connection setup latency.}}
Multicast gởi đến VCC một thiết lập hai chiều giữa điểm đến điểm vào khoảng
thời gian LEC đến BUS. Multicast tiến về VCC theo một cách VCC thiết lập đến LEC từ
BUS. Đặc trưng của nó là kết nối điểm đến đa điểm , với mổi một LEC như một nút lá.

Hình 27-14 chỉ ra kết nối dữ liệu LANE.

Điều khiển kết nối cho phép cấu hình trực tiếp VCC, điều khiển trực tiếp VCC, và phân
phối điều khiển VCC.
Cấu hình trực tiếp VCC là kỹ thuật thiếp lập hai chiều VCC bằng LEC đến LECS.
Điều khiển trực tiếp VCC là thiết lập hai chiều VCC bằng LEC đến LES. Phân phối điều
khiển VCC theo một phương hướng duy nhất thiết lập từ LES trở lại LEC.
Hình 27-15 giải thích các điều khiển kết nối LANE
Hoạt động của LANE
Hoạt động của một hệ thống LANE và các thành phần thoả thuận tốt nhất bởi
nghiên cứu các phạm vi hoạt động của LEC . Thực hiện khởi tạo và cấu hình , liên kết và
đăng ký với LEC, tìm kiếm và liên kết các BUS, và thực hiện truyền dữ liệu.
Khởi tạo và cấu hình
Lúc khởi tạo,một LEC tìm LECS để yêu cầu về thông tin cấu hình.Nó bắt đầu tiến
trình này khi LEC vẩn sử dụng được các địa chỉ ATM của nó, với đặc trưng tìm thấy địa
chỉ đăng ký. LEC phải quyết định vị trí của LECA. Để làm điều này, trước tiên LEC phải
định vị được LECS bằng phương pháp sau: sử dụng thủ tục định nghĩa ILMI để xác định
điạ chỉ LECS, bằng việc sử dụng tốt địa chỉ LECS, hay sử dụng tốt thường xuyên kết nối
đến LECS(VPI = 0,VCI = 17)
Sau khi LEC nhận ra NSAP của LECS , LEC thiết lập cấu hình trực tiếp VCC đến
LECS và gởi một thông điệp yêu cầu là LE_CONFIGURE_REQUEST. Nếu các dòng
đúng yêu cầu được tìm thấy , LECS trả về một thông điệp LE_CONFIGURE_REQUEST
đến LEC với thông tin cấu hình mà nó yêu cầu để kết nối đến đích ELAN, bao gồm các
bước sau: địa chỉ ATM của LES, kiểu của mô hình LAN cạnh tranh, kích thước lớn nhất
của gói trên ELAN, và tên ELAN

Nối và đăng ký với LES

Khi một LEC nối với LES và đăng ký địa chỉ ATM và MAC,nó sẽ theo ba bước
sau:
1. Sau khi LEC sử dụng được địa chỉ LES, LEC bắt buộc xoá hết kết nối đến LECS, thiết
lập điều khiển trực tiếp VCC đến LES, và gởi một thông điệp LE_JOIN_REQUEST trên
VCC đó. Điều này cho phép LEC đăng ký địa chỉ MAC và ATM của nó với LES và một
vài địa chỉ MAC khác cho proxying. Thông tin này duy trì cho nên không có hai LECS
nào cùng đăng ký cùng một địa chỉ ATM hoặc MAC.

2.Sau khi xác nhận thông điệp LE_JOIN_REQUEST , LES kiểm tra với LECS thong
qua việc mở kết nối, xác minh lời yêu cầu, và xác nhận thành viên của máy khách.

3.Lúc xác minh đúng , LES them LEC vào nút cuối hay nút lá của nó trong phân phối
điều khiển điểm đến nhiều

3.Lúc xác minh thành công, LES thêm vào LEC một nút con của điều khiển phân phối
điểm đến đa điểm VCC và đưa ra LEC một thông điệp báo thành công
LE_JOIN_RESPONSE chứa duy nhất một LECID (LAN Emulation Client ID). LECID
sử dụng qua LEC để lọc những truyền bá của mình từ BUS.

Tìm kiềm và nối BUS

Sau khi thành công giữa việc nối LEC và LECS, nhiệm vụ đầu tiên của nó là tìm
kiếm địa chỉ ATM của BUS để nối vào nhóm quảng bá và trở thành thành viên của
Emulated LAN.
Trước tiên LEC tạo ra một gói LE_ARP_REQUEST với địa chỉ MAC là
0xFFFFFFFF. Sau đó LEC gởi gói đặc biệt là LE_ARP trên việc điều khiển trực tiếp
VCC đến LES. LES công nhận rằng LEC tìm kiếm BUS và trả lời với địa chỉ ATM của
BUS trên phân phối điều khiển VCC.
 Khi LEC có địa chỉ ATM của BUS,nó nối BUS bằng việc tạo một gói tín hiệu
trước với địa chỉ ATM của BUS và thiết lập lên trên multicast-send VCC với BUS.Nhờ
vào sự xác nhận của tín hiệu yêu cầu
{{{. Upon receipt of the signaling
request, the BUS adds the LEC as a leaf on its point-to-multipoint multicast forward VCC. The LEC is
now a member of the ELAN and is ready for data transfer.}}}
Truyền dữ liệu
Trạng thái cuối , truyền dữ liệu ,bao gồm giải quyết địa chỉ ATM của đích đến
LEC và truyền dữ liệu hiện tại,mà có thể bao gồm nhiều thủ tục.
Khi LEC có gói dữ liệu gởi đến đích mà không rõ địa chỉ MAC,nó phải nhận ra
địa chỉ MAC của đích đến LEC thông qua địa chỉ ngoại lệ có thể làm được. Để hoàn
thành điều này , trước tiên LEC gởi khung dữ liệu cho BUS để phân phối cho tất cả LECs
qua trên ELAN với nhiều trạng thái tiếp tới VCC.Làm điều này bởi vì việc giải quyết địa
chỉ ATM có thể thời gian và nhiều giao thức mạng không chấp nhận độ trể. Khi đó LEC
gởi một khung điều khiển LE_ARP_Request (LANE Emulation Address Resolution
Protocol Request) đến LES qua một VCC điều khiển trực tiếp. Nếu LES nhận được trả
lời , nó đáp lại với địa chỉ ATM của LEC có địa chỉ MAC trong nghi vấn đó. Nếu LES
không biết để trả lời, nó đưa LE_ARP_REQUEST cho một vài hoặc tất cả LECs (dưới
nguyên tắc giống như BUS tung ra các khung dữ liệu hiện tại, nhưng lên khắp các kết nối
trực tiếp và phân phối điều khiển thay cho VCCs gồm có gởi multicast và tiếp tới
multicast VCC sử dụng do BUS ). Nếu các thiết bị brigde hay switching với phần mềm
tham gia LEC trong tồn tại ELAN,chúng trả lời đến LE_ARP_REQUEST nếu chúng
giúp ích cho thiết bị LAN với yêu cầu của địa chỉ MAC. Điều này gọi là proxy service.
Trong trường hợp của việc truyền dữ liệu hiện tại, nếu thông điệp LE_ARP được
thừa nhận , LEC dựng lên một dữ liệu trực tiếp VCC đến đích LEC và sử dụng điều đó
cho việc truyền dữ liệu khá hơn đường dẫn BUS.Trước khi nó có thể làm điều này , tuy
nhiên,LEC cần sử dụng ngay vào quy trình LANE, đảm bảo rằng tất cả các gói trước đây
gởi đi đến BUS được chuyển giao đến theo thứ tự đích của dữ liệu trực tiếp VCC.Vào
ngay trong quy trình, một khung điều khiển được gởi dưới đường truyền đầu tiên theo gói
cuối cùng. LEC chờ đến khi đích đến xác nhận đã nhận được của gói flush trước khi sử
dụng đường dẩn thứ hai để gới nhiều gói .

III.6. MPOA (MULTIPROTOCOL OVER ATM)

MPOA là một sự kết hợp cơ bản của LANE và NHRP. MPOA cải tiến LANE
bằng cách cho phép lưu lượng inter-ELAN đi qua các kết nối tắt hơn là qua các router.
Việc xây dựng nó như một lối tắt, NHRP được sử dụng để phân giải địa chỉ IP đích thành
địa chỉ ATM. Theo hướng này, MPOA là một kết nối định tuyến của lớp 3 và cầu nối với
lớp 2

III.6.1. MÔI TRƯỜNG CỦA MPOA

Môi trường MPOA điển hình là một mạng ATM với những máy ATM và các thiết
bị ngoài lề được gắn với nó. Một thiết bị ngoài lề có thể là một cầu nối kết nối một legacy
LAN (ví dụ Ether hoặc Token Ring) tới một ELAN, hoặc một router để kết nối một mạng
con non-ATM đến một mạng ATM. Trên mạng ATM này xác định một số của những
ELAN và LIS. Đặc trưng của một LIS thì tương tự một ELAN và những LAN kế thừa là
để làm cầu nối tới nó. Nhiệm vụ của giao thức MPOA là tìm ra phương pháp tốt nhất
giữa hai máy trong môi trường này để giao tiếp một cách hiệu quả với những máy khác.
Nếu một hệ thống thừa kế được gắn vào một thiết bị ngoài lề cần gửi dữ liệu đến một hệ
thống thừa kế khác gắn vào một thiết bị ngoài rìa khác. Hiển nhiên cách tiếp cận tốt nhất
là thiết lập kết nối trực tiếp giữa hai thiết bị ngoài rìa và truyền lưu lượng thông qua kết
nối này. Trong trường hợp này, thiết bị ngoài lề mà được người gửi gắn gọi là một lối
vào điểm cuối và thiết bị ngoài rìa mà được người nhận gắn gọi là một lối ra điểm cuối.
Việc giao tiếp chính của MPOA là xây dựng kết nối end –to –end giữa một lối vào điểm
cuối và một lối ra điểm cuối cho việc giao tiếp có hiệu quả. Nếu chúng ta thấy việc giao
tiếp giữa hai hệ thống thừa kế gắn vào những thiết bị ngoài lề khác nhau giống như giữa
hai thiết bị ngoài lề, chúng ta có thể đơn giản hoá sự tranh chấp bằng cách chỉ xem xét
những giao tiếp giữa các hệ thống cuối ( Những máy và các thiết bị ngoài lề.)

III.6.2. HOẠT ĐỘNG CỦA MPOA

MPOA is built on top of LANE. If two end systems are in the same ELAN, the traffic
between them
follows the LANE specification. With LANE, inter-ELAN traffic has to go through a
router. MPOA
allows shortcuts between ELANs by integrating NHRP functionalities into it. It allows an
end system to
obtain the ATM address of another end system that lies in a different ELAN and establish
end-to-end
connection with it. Such shortcuts are created autotmatically through a mechanism called
flow detection.
Before the direct connection between the end systems is built, inter-ELAN traffic is still
forwarded to
routers. However, an entity called MPOA Client (MPC) that runs on each end system is
capable of
detecting traffic. When it finds out that an end system has recently sent a significant
amount of traffic
destined for the same destination to the router, it will try to establish a connection to the
egress point
which is "nearest" to the destination. An entity called MPOA server runs in a MPOA
environment to
resolve the ATM address of the egress point given the IP address of the destination.
Hình.3 MPOA

Chúng ta hãy xem một ví dụ:

Trong hình 3 chứa một môi trường MPOA. E1,E2 và E3 là những thiết bị rìa kết
nối tới một mạng ATM. Mỗi thiết bị rìa kết nối 2 máy tới mạng ATM. Hai ELAN được
xác định rõ trên mạng ATM, LAN1 gồm có ,máy A1, A2 và A3 ; LAN2 gồm có máy
B1,B2 và B3. LIS 1 được định rõ trên LAN1 và LIS 2 được định rõ trên LAN 2. Router R
là một thành viên của cả LIS 1 và LIS 2. Nếu A1 muốn giao tiếp với A2 thì điều đó dễ
dàng thực hiện thông qua những thủ tục trong LANE khi A1 và A2 liên quan tới cùng
ELAN. Tuy nhiên, nếu A1 muốn giao tiếp với B2, đối với LANE E1 phải gửi packet từ
A1 tới router R và R sẽ chuyển tiếp gói tin đó tới E2, sau đó tới B2. Đây rõ ràng không
phải là một phương pháp tốt. Đối với MPOA, một thực thể đựoc gọi là MPOA server
(MPS) đang chạy trên R sẽ biết thiết bị ngoài lề để giao tiếp tới một địa chỉ IP đích.
Trong ví dụ này, MPS đang chạy trên R, nếu A1 muốn giao tiếp với B2, đầu tiên nó chỉ
gửi lưu lượng tới R như trong LANE. Tuy nhiên, E1 thì đủ thông minh để kiểm tra dòng
lưu lượng này. Sau đó E1 sẽ giao tiếp với R để biết thiết bị ngoài lề nào gần với đích B2
nhất. Sau đó R trả lời với địa chỉ ATM của E2, tiếp theo E1 xây dựng một kết nối tới E2
và gửi tất cả lưu lượng từ A1 tới B2 theo kết nối này. Trong ví dụ này chỉ có một MPOA
server, trong môi trường MPOA thực sự có thể có nhiều MPS ở một hoặc nhiều ELAN.
Một MPS chứa chức năng của NHS, nghĩa là nếu một MPS có thể không phân giải địa
chỉ IP nó sẽ chuyển tiếp truy vấn tới những MPS khác. MPOA hỗ trợ tình trạng chia cắt
trong việc tính toán định tuyến và chuyển tiếp dữ liệu. Một router truyền thống có cả
những chức năng trên. Tuy nhiên trong môi trường MPOA nếu mỗi thiết bị rìa là một
full-fledged router nó cũng sẽ rất đắt tiền. MPOA gỡ bỏ những chức năng trong việc tính
toán định tuyến từ những thiết bị ngoài lề và một chức năng của server định tuyến được
bao gồm trong MPS để hướng dẫn những thiết bị ngoài lề chuyển dữ liệu đến đúng đích.
Multiprotocol over ATM
Multiprotocol over ATM (MPOA) provides a method of transmitting data between ELANs without
needing to continuously pass through a router. Normally, data passes through at least one router to get
from one ELAN to another. This is normal per-hop routing as experienced in LAN environments.
MPOA, however, enables devices in different ELANs to communicate without needing to travel hop by
hop.
Figure 27-16 illustrates the process without MPOA in part A and with MPOA in part B. With
MPOA-enabled devices, only the first few frames between devices pass through routers. This is called
the default path. The frames pass from ELAN to ELAN through appropriate routers. After a few frames
follow the default path, the MPOA devices discover the NSAP address of the other device and then build
a direct connection called the shortcut for the subsequent frames in the flow.
The edge devices that generate the ATM traffic are called multiprotocol clients (MPC) and may be an
ATM-attached workstation, or a router. The inter-ELAN routers are called multiprotocol servers (MPS)
and assist the MPCs in discovering how to build a shortcut. MPSs are always routers.
This reduces the load on routers because the routers do not need to sustain the continuous flow between
devices. Furthermore, MPOA can reduce the number of ATM switches supporting a connection, freeing
up virtual circuits and switch resources in the ATM network. Figure 27-16 illustrates the connection
before and after the shortcut is established.
Note that MPOA does not replace LANE. In fact, MPOA requires LANE version 2.

MPOA over ALL5

Multiprotocol Encapsulation over ATM Adaptation Layer 5

Status of this Memo

This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
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 memo describes two encapsulations methods for carrying network

interconnect traffic over ATM AAL5. The first method allows
multiplexing of multiple protocols over a single ATM virtual circuit
whereas the second method assumes that each protocol is carried over
a separate ATM virtual circuit.

1. Introduction

Asynchronous Transfer Mode (ATM) based networks are of increasing

interest for both local and wide area applications. This memo
describes two different methods for carrying connectionless network
interconnect traffic, routed and bridged Protocol Data Units (PDUs),
over an ATM network. The first method allows multiplexing of
multiple protocols over a single ATM virtual circuit. The protocol
of a carried PDU is identified by prefixing the PDU by an IEEE 802.2
Logical Link Control (LLC) header. This method is in the following
called "LLC Encapsulation" and a subset of it has been earlier
defined for SMDS [1]. The second method does higher-layer protocol
multiplexing implicitly by ATM Virtual Circuits (VCs). It is in the
following called "VC Based Multiplexing".
 ATM is a cell based transfer mode that requires variable length user
information to be segmented and reassembled to/from short, fixed
length cells. This memo doesn't specify a new Segmentation And
Reassembly (SAR) method for bridged and routed PDUs. Instead, the
PDUs are carried in the Payload field of Common Part Convergence
Sublayer (CPCS) PDU of ATM Adaptation Layer type 5 (AAL5) [2].

Note that this memo only describes how routed and bridged PDUs are
carried directly over the CPCS of AAL5, i.e., when the Service
Specific Convergence Sublayer (SSCS) of AAL5 is empty. If Frame

Heinanen [Page 1]

RFC 1483 Multiprotocol over AAL5 July 1993

Relay Service Specific Convergence Sublayer (FR-SSCS), as defined in

I.36x.1 [3], is used over the CPCS of AAL5, then routed and bridged
PDUs are carried using the NLPID multiplexing method described in RFC
1294 [4]. Appendix A (which is for information only) shows the
format of the FR-SSCS-PDU as well as how IP and CLNP PDUs are
encapsulated over FR-SSCS according to RFC 1294.

2. Selection of the Multiplexing Method

It is envisioned that VC Based Multiplexing will be dominant in

environments where dynamic creation of large numbers of ATM VCs is
fast and economical. These conditions are likely to first prevail in
private ATM networks. LLC Encapsulation, on the other hand, may be
desirable when it is not practical for one reason or another to have
a separate VC for each carried protocol. This is the case, for
example, if the ATM network only supports (semi) Permanent Virtual
Circuits (PVCs) or if charging depends heavily on the number of
simultaneous VCs.

When two ATM stations wish to exchange connectionless network

interconnect traffic, selection of the multiplexing method is done
either by manual configuration (in case of PVCs) or by B-ISDN
signalling procedures (in case of Switched VCs). The details of B-
ISDN signalling are still under study in CCITT [5]. It can, however,
be assumed that B-ISDN signalling messages include a "Low layer
compatibility" information element, which will allow negotiation of
AAL5 and the carried (encapsulation) protocol.

3. AAL5 Frame Format

No matter which multiplexing method is selected, routed and bridged

PDUs shall be encapsulated within the Payload field of AAL5 CPCS-PDU.
The format of the AAL5 CPCS-PDU is given below:
Heinanen [Page 2]

RFC 1483 Multiprotocol over AAL5 July 1993

AAL5 CPCS-PDU Format

+-------------------------------+
| . |
| . |
| CPCS-PDU Payload |
| up to 2^16 - 1 octets) |
| . |
| . |
+-------------------------------+
| PAD ( 0 - 47 octets) |
+-------------------------------+ -------
| CPCS-UU (1 octet ) |
+-------------------------------+
| CPI (1 octet ) |
+-------------------------------+CPCS-PDU Trailer
| Length (2 octets) |
+-------------------------------|
| CRC (4 octets) |
+-------------------------------+ -------

The Payload field contains user information up to 2^16 - 1 octets.

The PAD field pads the CPCS-PDU to fit exactly into the ATM cells
such that the last 48 octet cell payload created by the SAR sublayer
will have the CPCS-PDU Trailer right justified in the cell.

The CPCS-UU (User-to-User indication) field is used to transparently

transfer CPCS user to user information. The field has no function
under the multiprotocol ATM encapsulation described in this memo and
can be set to any value.

The CPI (Common Part Indicator) field alings the CPCS-PDU trailer to
64 bits. Possible additional functions are for further study in
CCITT. When only the 64 bit alignment function is used, this field
shall be codes as 0x00.

The Length field indicates the length, in octets, of the Payload

field. The maximum value for the Length field is 65535 octets. A
 Length field coded as 0x00 is used for the abort function.

The CRC field protects the entire CPCS-PDU except the CRC field
itself.

4. LLC Encapsulation

LLC Encapsulation is needed when several protocols are carried over

the same VC. In order to allow the receiver to properly process the
incoming AAL5 CPCS-PDU, the Payload Field must contain information

Heinanen [Page 3]

RFC 1483 Multiprotocol over AAL5 July 1993

necessary to identify the protocol of the routed or bridged PDU. In

LLC Encapsulation this information is encoded in an LLC header placed
in front of the carried PDU.

Although this memo only deals with protocols that operate over LLC
Type 1 (unacknowledged connectionless mode) service, the same
encapsulation principle applies also to protocols operating over LLC
Type 2 (connection-mode) service. In the latter case the format
and/or contents of the LLC header would differ from what is shown
below.

4.1. LLC Encapsulation for Routed Protocols

In LLC Encapsulation the protocol of the routed PDU is identified by

prefixing the PDU by an IEEE 802.2 LLC header, which is possibly
followed by an IEEE 802.1a SubNetwork Attachment Point (SNAP) header.
In LLC Type 1 operation, the LLC header consists of three one octet
fields:

+------+------+------+
| DSAP | SSAP | Ctrl |
+------+------+------+

In LLC Encapsulation for routed protocols, the Control field has

always value 0x03 specifying Unnumbered Information Command PDU.

The LLC header value 0xFE-FE-03 identifies that a routed ISO PDU (see
[6] and Appendix B) follows. The Control field value 0x03 specifies
Unnumbered Information Command PDU. For routed ISO PDUs the format
of the AAL5 CPCS-PDU Payload field shall thus be as follows:

Payload Format for Routed ISO PDUs

+-------------------------------+
| LLC 0xFE-FE-03 |
+-------------------------------+
| . |
| ISO PDU |
| (up to 2^16 - 4 octets) |
| . |
 +-------------------------------+

The routed ISO protocol is identified by a one octet NLPID field that
is part of Protocol Data. NLPID values are administered by ISO and
CCITT. They are defined in ISO/IEC TR 9577 [6] and some of the
currently defined ones are listed in Appendix C.

An NLPID value of 0x00 is defined in ISO/IEC TR 9577 as the Null

Network Layer or Inactive Set. Since it has no significance within

Heinanen [Page 4]

RFC 1483 Multiprotocol over AAL5 July 1993

the context of this encapsulation scheme, a NLPID value of 0x00 is

invalid under the ATM encapsulation.

It would also be possible to use the above encapsulation for IP,

since, although not an ISO protocol, IP has an NLPID value 0xCC
defined for it. This format must not be used. Instead, IP is
encapsulated like all other routed non-ISO protocols by identifying
it in the SNAP header that immediately follows the LLC header.

The presence of a SNAP header is indicated by the LLC header value

0xAA-AA-03. A SNAP header is of the form

+------+------+------+------+------+
| OUI | PID |
+------+------+------+------+------+

The three-octet Organizationally Unique Identifier (OUI) identifies

an organization which administers the meaning of the following two
octet Protocol Identifier (PID). Together they identify a distinct
routed or bridged protocol. The OUI value 0x00-00-00 specifies that
the following PID is an EtherType.

The format of the AAL5 CPCS-PDU Payload field for routed non-ISO PDUs
shall thus be as follows:

Payload Format for Routed non-ISO PDUs

+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-00-00 |
+-------------------------------+
| EtherType (2 octets) |
+-------------------------------+
| . |
| Non-ISO PDU |
| (up to 2^16 - 9 octets) |
| . |
+-------------------------------+

In the particular case of an Internet IP PDU, the Ethertype value is

 0x08-00:

Heinanen [Page 5]

RFC 1483 Multiprotocol over AAL5 July 1993

Payload Format for Routed IP PDUs

+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-00-00 |
+-------------------------------+
| EtherType 0x08-00 |
+-------------------------------+
| . |
| IP PDU |
| (up to 2^16 - 9 octets) |
| . |
+-------------------------------+

This is compatible with RFC 1042 [7]. Any changes in the header
format specified in RFC 1042 should be followed by this memo.

4.2. LLC Encapsulation for Bridged Protocols

In LLC Encapsulation bridged PDUs are encapsulated by identifying the

type of the bridged media in the SNAP header. As with routed non-ISO
protocols, the presence of the SNAP header is indicated by the LLC
header value 0xAA-AA-03. With bridged protocols the OUI value in the
SNAP header is the 802.1 organization code 0x00-80-C2 and the actual
type of the bridged media is specified by the two octet PID.
Additionally, the PID indicates whether the original Frame Check
Sequence (FCS) is preserved within the bridged PDU. The media type
(PID) values that can be used in ATM encapsulation are listed in
Appendix B.

The AAL5 CPCS-PDU Payload field carrying a bridged PDU shall,

therefore, have one of the following formats. Padding is added after
the PID field if necessary in order to align the user information
field of the bridged PDU at a four octet boundary.
Heinanen [Page 6]

RFC 1483 Multiprotocol over AAL5 July 1993

Payload Format for Bridged Ethernet/802.3 PDUs

+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-01 or 0x00-07 |
+-------------------------------+
| PAD 0x00-00 |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (if PID is 0x00-01) |
+-------------------------------+

Payload Format for Bridged 802.4 PDUs

+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-02 or 0x00-08 |
+-------------------------------+
| PAD 0x00-00-00 |
+-------------------------------+
| Frame Control (1 octet) |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (if PID is 0x00-02) |
+-------------------------------+
Heinanen [Page 7]

RFC 1483 Multiprotocol over AAL5 July 1993

Payload Format for Bridged 802.5 PDUs

+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-03 or 0x00-09 |
+-------------------------------+
| PAD 0x00-00-XX |
+-------------------------------+
| Frame Control (1 octet) |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (if PID is 0x00-03) |
+-------------------------------+

Note that the 802.5 Access Control (AC) field has no significance
outside the local 802.5 subnetwork. It can thus be regarded as the
last octet of the three octet PAD field, which can be set to any
value (XX).

Payload Format for Bridged FDDI PDUs

+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-04 or 0x00-0A |
+-------------------------------+
| PAD 0x00-00-00 |
+-------------------------------+
| Frame Control (1 octet) |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
 +-------------------------------+
| LAN FCS (if PID is 0x00-04) |
+-------------------------------+

Heinanen [Page 8]

RFC 1483 Multiprotocol over AAL5 July 1993

Payload Format for Bridged 802.6 PDUs

+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-0B |
+---------------+---------------+ ------
| Reserved | BEtag | Common
+---------------+---------------+ PDU
| BAsize | Header
+-------------------------------+ -------
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| |
| Common PDU Trailer |
| |
+-------------------------------+

Note that in bridged 802.6 PDUs, there is only one choice for the PID
value, since the presence of a CRC-32 is indicated by the CIB bit in
the header of the MAC frame.

The Common Protocol Data Unit (PDU) Header and Trailer are conveyed
to allow pipelining at the egress bridge to an 802.6 subnetwork.
Specifically, the Common PDU Header contains the BAsize field, which
contains the length of the PDU. If this field is not available to
the egress 802.6 bridge, then that bridge cannot begin to transmit
the segmented PDU until it has received the entire PDU, calculated
the length, and inserted the length into the BAsize field. If the
field is available, the egress 802.6 bridge can extract the length
from the BAsize field of the Common PDU Header, insert it into the
corresponding field of the first segment, and immediately transmit
the segment onto the 802.6 subnetwork. Thus, the bridge can begin
transmitting the 802.6 PDU before it has received the complete PDU.

Note that the Common PDU Header and Trailer of the encapsulated frame
should not be simply copied to the outgoing 802.6 subnetwork because
the encapsulated BEtag value may conflict with the previous BEtag
value transmitted by that bridge.
 An ingress 802.6 bridge can abort an AAL5 CPCS-PDU by setting its
Length field to zero. If the egress bridge has already begun
transmitting segments of the PDU to an 802.6 subnetwork and then

Heinanen [Page 9]

RFC 1483 Multiprotocol over AAL5 July 1993

notices that the AAL5 CPCS-PDU has been aborted, it may immediately
generate an EOM cell that causes the 802.6 PDU to be rejected at the
receiving bridge. Such an EOM cell could, for example, contain an
invalid value in the Length field of the Common PDU Trailer.

+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-0E |
+-------------------------------+
| |
| BPDU as defined by |
| 802.1(d) or 802.1(g) |
| |
+-------------------------------+

5. VC Based Multiplexing

In VC Based Multiplexing, the carried network interconnect protocol

is identified implicitly by the VC connecting the two ATM stations,
i.e. each protocol must be carried over a separate VC. There is
therefore no need to include explicit multiplexing information in the
Payload of the AAL5 CPCS-PDU. This results in minimal bandwidth and
processing overhead.

As indicated above, the carried protocol can be either manually

configured or negotiated dynamically during call establishment using
signalling procedures. The signalling details will be defined later
in other RFCs when the relevant standards have become available.

5.1. VC Based Multiplexing of Routed Protocols

PDUs of routed protocols shall be carried as such in the Payload of

the AAL5 CPCS-PDU. The format of the AAL5 CPCS-PDU Payload field
thus becomes:

Payload Format for Routed PDUs

+-------------------------------+
| . |
| Carried PDU |
| (up to 2^16 - 1 octets) |
| . |
 | . |
+-------------------------------+

Heinanen [Page 10]

RFC 1483 Multiprotocol over AAL5 July 1993

5.2. VC Based Multiplexing of Bridged Protocols

PDUs of bridged protocols shall be carried in the Payload of the AAL5

CPCS-PDU exactly as described in section 4.2 except that only the
fields after the PID field are included. The AAL5 CPCS-PDU Payload
field carrying a bridged PDU shall, therefore, have one of the
following formats.

Payload Format for Bridged Ethernet/802.3 PDUs

+-------------------------------+
| PAD 0x00-00 |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (VC dependent option) |
+-------------------------------+

Payload Format for Bridged 802.4/802.5/FDDI PDUs

+-------------------------------+
| PAD 0x00-00-00 or 0x00-00-XX |
+-------------------------------+
| Frame Control (1 octet) |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (VC dependent option) |
+-------------------------------+

Note that the 802.5 Access Control (AC) field has no significance
outside the local 802.5 subnetwork. It can thus be regarded as the
last octet of the three octet PAD field, which in case of 802.5 can
be set to any value (XX).
Heinanen [Page 11]

RFC 1483 Multiprotocol over AAL5 July 1993

Payload Format for Bridged 802.6 PDUs

+---------------+---------------+ -------
| Reserved | BEtag | Common
+---------------+---------------+ PDU
| BAsize | Header
+-------------------------------+ -------
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| |
| Common PDU Trailer |
| |
+-------------------------------+

Payload Format for BPDUs

+-------------------------------+
| |
| BPDU as defined by |
| 802.1(d) or 802.1(g) |
| |
+-------------------------------+

In case of Ethernet, 802.3, 802.4, 802.5, and FDDI PDUs the presense
or absence of the trailing LAN FCS shall be identified implicitly by
the VC, since the PID field is not included. PDUs with the LAN FCS
and PDUs without the LAN FCS are thus considered to belong to
different protocols even if the bridged media type would be the same.

6. Bridging in an ATM Network

An ATM interface acting as a bridge must be able to flood, forward,

and filter bridged PDUs.

Flooding is performed by sending the PDU to all possible appropriate

destinations. In the ATM environment this means sending the PDU
through each relevant VC. This may be accomplished by explicitly
copying it to each VC or by using a multicast VC.

To forward a PDU, a bridge must be able to associate a destination

MAC address with a VC. It is unreasonable and perhaps impossible to
require bridges to statically configure an association of every
 possible destination MAC address with a VC. Therefore, ATM bridges

Heinanen [Page 12]

RFC 1483 Multiprotocol over AAL5 July 1993

must provide enough information to allow an ATM interface to

dynamically learn about foreign destinations beyond the set of ATM
stations.

To accomplish dynamic learning, a bridged PDU shall conform to the

encapsulation described within section 4. In this way, the receiving
ATM interface will know to look into the bridged PDU and learn the
association between foreign destination and an ATM station.

7. For Further Study

Due to incomplete standardization of ATM multicasting, addressing,

and signalling mechanisms, details related to the negotiation of the
multiplexing method as well as address resolution had to be left for
further RFCs.

Acknowledgements

This document has evolved from RFCs [1] and [4] from which much of
the material has been adopted. Thanks to their authors T. Bradley,
C. Brown, A. Malis, D. Piscitello, and C. Lawrence. In addition,
the expertise of the ATM working group of the IETF has been
invaluable in completing the document. Special thanks Brian
Carpenter of CERN, Rao Cherukuri of IBM, Dan Grossman of Motorola,
Joel Halpern of Network Systems, Bob Hinden of Sun Mircosystems, and
Gary Kessler of MAN Technology Corporation for their detailed
contributions.

Security Considerations

Security issues are not addressed in this memo.

References

[1] Piscitello, D. and Lawrence, C., "The Transmission of IP

Datagrams over the SMDS Service". RFC 1209, Bell Communications
Research, March 1991.

[2] CCITT, "Draft Recommendation I.363". CCITT Study Group XVIII,

Geneva, 19 - 29 January, 1993.

[3] CCITT, "Draft Recommendation I.36x.1". CCITT Study Group XVIII,

Geneva, 19-29 January, 1993.

[4] Bradley, T., Brown, C., and Malis, A., "Multiprotocol

Interconnect over Frame Relay". RFC 1294, Wellfleet
Communications, Inc. and BBN Communications, January 1992.
Heinanen [Page 13]

RFC 1483 Multiprotocol over AAL5 July 1993

[5] CCITT, "Draft text for Q.93B". CCITT Study Group XI, 23
September - 2 October, 1992.

[6] Information technology - Telecommunications and Information

Exchange Between Systems, "Protocol Identification in the
Network Layer". ISO/IEC TR 9577, October 1990.

[7] Postel, J. and Reynolds, J., "A Standard for the Transmission of
IP Datagrams over IEEE 802 Networks". RFC 1042, ISI, February,
1988.

Appendix A. Multiprotocol Encapsulation over FR-SSCS

I.36x.1 defines a Frame Relaying Specific Convergence Sublayer (FR-

SSCS) to be used on the top of the Common Part Convergence Sublayer
CPCS) of the AAL type 5 for Frame Relay/ATM interworking. The
service offered by FR-SSCS corresponds to the Core service for Frame
Relaying as described in I.233.

An FR-SSCS-PDU consists of Q.922 Address field followed by Q.922

Information field. The Q.922 flags and the FCS are omitted, since
the corresponding functions are provided by the AAL. The figure
below shows an FR-SSCS-PDU embedded in the Payload of an AAL5 CPCS-
PDU.

FR-SSCS-PDU in Payload of AAL5 CPCS-PDU

+-------------------------------+ -------
| Q.922 Address Field | FR-SSCS-PDU Header
| (2-4 octets) |
+-------------------------------+ -------
| . |
| . |
| Q.922 Information field | FR-SSCS-PDU Payload
| . |
| . |
+-------------------------------+ -------
| AAL5 CPCS-PDU Trailer |
+-------------------------------+

Routed and bridged PDUs are encapsulated inside the FR-SSCS-PDU as

defined in RFC 1294. The Q.922 Information field starts with a Q.922
Control field followed by an optional Pad octet that is used to align
the remainder of the frame to a convenient boundary for the sender.
The protocol of the carried PDU is then identified by prefixing the
PDU by an ISO/CCITT Network Layer Protocol ID (NLPID).

In the particular case of an IP PDU, the NLPID is 0xCC and the FR-
SSCS-PDU has the following format:
Heinanen [Page 14]

RFC 1483 Multiprotocol over AAL5 July 1993

FR-SSCS-PDU Format for Routed IP PDUs

+-------------------------------+
| Q.922 Addr Field |
| (2 or 4 octets) |
+-------------------------------+
| 0x03 (Q.922 Control) |
+-------------------------------+
| NLPID 0xCC |
+-------------------------------+
| . |
| IP PDU |
| (up to 2^16 - 5 octets) |
| . |
+-------------------------------+

Note that according to RFC 1294 the Q.922 Address field shall be
either 2 or 4 octets, i.e., a 3 octet Address field is not supported.

In the particular case of a CLNP PDU, the NLPID is 0x81 and the FR-
SSCS-PDU has the following format:

FR-SSCS-PDU Format for Routed CLNP PDUs

+-------------------------------+
| Q.922 Addr Field |
| (2 or 4 octets) |
+-------------------------------+
| 0x03 (Q.922 Control) |
+-------------------------------+
| NLPID 0x81 |
+-------------------------------+
| . |
| Rest of CLNP PDU |
| (up to 2^16 - 5 octets) |
| . |
+-------------------------------+

Note that in case of ISO protocols the NLPID field forms the first
octet of the PDU itself and shall thus not be repeated.

The above encapsulation applies only to those routed protocols that

have a unique NLPID assigned. For other routed protocols (and for
bridged protocols), it is necessary to provide another mechanism for
easy protocol identification. This can be achieved by using an NLPID
value 0x80 to indicate that an IEEE 802.1a SubNetwork Attachment
Point (SNAP) header follows.

See RFC 1294 for more details related to multiprotocol encapsulation

over FRCS.
Heinanen [Page 15]

RFC 1483 Multiprotocol over AAL5 July 1993

Appendix B. List of Locally Assigned values of OUI 00-80-C2

with preserved FCS w/o preserved FCS Media

------------------ ----------------- --------------
0x00-01 0x00-07 802.3/Ethernet
0x00-02 0x00-08 802.4
0x00-03 0x00-09 802.5
0x00-04 0x00-0A FDDI
0x00-05 0x00-0B 802.6
0x00-0D Fragments
0x00-0E BPDUs

Appendix C. Partial List of NLPIDs

0x00 Null Network Layer or Inactive Set (not used with ATM)
0x80 SNAP
0x81 ISO CLNP
0x82 ISO ESIS
0x83 ISO ISIS
0xCC Internet IP

III.7. P AR AND I-PNNI

 Trong MPOA và NHRP,các kết nối giữa các router khác nhau và server được cấu
hình trước khi kết nối . Khi một mạng trở nên rộng lớn nó sẻ đòi hỏi có những cấu hình
phức tạp và có lỗi .PNNI tăng them

. When the network becomes large it is expected that such configuration can be complex
and
error-prone. PNNI augmented routing (PAR) tackles this problem by allowing the routers
take part in the
PNNI routing protocol and make connections to other routers on demand based on the
reachability
information it gets from the exchange of PNNI messages with other switches and routers.
With PAR, the
routers will still run the legacy IP routing protocols like OSPF and IGRP. The information
it gets by
taking part in the PNNI message exchange helps it establish connections with other
routers. [Dorling]
I-PNNI proposes the use of PNNI as the only routing protocol in an environment of ATM
network and
ATM-attached routers. A peer group may include both routers and switches. Both
signaling requsts and
IP packets are routed using the PNNI protocol. In this way, IP can benefit from the QoS
guarantee and
the scalability of the PNNI. In I-PNNI, both routers and switches will exchange PTSPs
with their
neighbours. Both IP addresses and ATM NSAP addresses can be advertised in PTSP
packets.
ATM switches will advertise their reachability to certain ATM addresses summarized as a
prefix of
20-byte ATM NSAP address while IP routers advertise reachiablity to certain IP addresses
summarized
as a prefix of 16 bit IP address.

TONG KET

Khả năng để hổ trợ cho truyền thong legacy IP là cần thiết đối với việc thành công
của những mạng ATM. Nghiên cứu ATM cho đến nay là kiến trúc mạng LAN khác
,classical IP over ATM là đơn giản để thực thi. Tuy nhiên , mặt hạn chế của nó là truyền
thông inter-LIS đi thông qua một router chắc chắn dù cho hai phần kết nối trực tiếp đến
mạng ATM. NHRP ngăn chặn vấn đề này bằng cách tăng lên với một giao thức giải pháp
địa chỉ vì thế đường nối tắt có thể thiết lập giữa các hệ thống cuối thuộc về các LIS không
giống nhau. Để thúc đẩy sự triển khai kỹ thuật của ATM, LANE tranh đua với Ethernet
và Token Ring LANs trên mạng ATM vì vậy tồn tại phần mềm IP chạy trên LANs và trên
cả ELANs mà không có sự thay đổi nào. Tuy nhiên , ELAN có các điểm hạn chế như
classical IP over ATm, đó là truyền thông inter-ELAN có thông qua một router . MPOA
kết hợp với công nghệ LANE và NHRP để hổ trợ cho cả việc định tuyến IP và làm cầu
nối giữa LAN với mạng ATM. Thêm vào đó là các kiểu dữ liệu mới, hai sơ đồ định tuyến
PAR và I-PNNI được đưa ra sử dụng trong môi trường mạng ATM và các router.PAR cho
phép các router tự phát hiện ra các router khác và xây dung kết nối ATM để thay đổi các
thông tin định tuyến.I-PNNI cho phép giao thức PNNI có thể sử dụng trong các mạng
ghép bao gồm ATM switch và các router.Thật ra các cải tiến về định tuyến có thể sử dụng
ngang hang với một vài kiểu dữ liệu

CHƯƠNG IV: CẤU HÌNH IP OVER ATM

Phần này mô tả việc cấu hình một cổng trên một ATM switch router để cho phép một
Classical IP over ATM kết nối đến bộ xử lý định tuyến của ATM switch router.

IV.1. CẤU HÌNH CLIP TRONG MÔI TRƯỜNG SVC (switched virtual circuit)

Phần này mô tả việc cấu hình IP over ATM trong một môi trường SVC. Nó đòi
hỏi một người quản trị mạng để cấu hình địa chỉ ATM của chính thiết bị và cấu hình một
ATM ARP server vào trong mỗi thiết bị client

Hình 12-1 mô tả các bước cần thiết để cài đặt một kết nối Classiacal IP over ATM giữa
ATM switch router client A và client B.

Hình 12-1: Ví dụ về cài đặt kết nối Classical IP over ATM.

Bước 1: Gói IP ban đầu được gửi bằng cách Client A khởi tạo một yêu cầu tới ARP server
để tìm địa chỉ IP và địa chỉ ATM tương ứng cảu client B trong bảng ARP của ARP server.
Bước 2: ARP server gửi ngược lại một phản hồi tới client A với địa chỉ ATM trùng khớp.

Bước 3: Client A sử dụng địa chỉ ATM mà nó vừa nhận từ ARP server để cài đặt một
SVC trực tiếp đến client B.

Bước 4: Khi client B phản hồi với một gói IP tới client A, nó cũng khởi tạo một truy vấn
tới ARP server.

Chú ý: Khi client B nhận địa chỉ ATM cho client A, nó thường nhận ra rằng nó đã
sẵn sàng có một cuộc gọi thiết lập tới địa chỉ ATM của client A và không thiết lập cuộc
gọi khác.

Bước 5: Mỗi lần kết nối được biết tất cả client, chúng giao tiếp trực tiếp trên SVC.

Trong việc thực thi của cisco, ATM ARP client cố gắng duy trì một kết nối đến ATM ARP
server. ATM ARP server có thể mất kết nối, nhưng client cố gắng mỗi lần một phút để
mang kết nối trở lại. Không có thông điệp lỗi nào được đưa ra khi một kết nối bị lỗi.
Nhưng client sẽ không định tuyến những gói tin cho đến khi ATM ARP server được kết
nối và chuyển đổi những địa chỉ mạng IP.

Mỗi gói tin với một địa chỉ IP không xác định, client gửi một yêu cầu ATM ARP tới ARP
server. Cho đến khi địa chỉ đó được phân giải, một vài gói IP đã được định tuyến tới giao
diện ATM làm cho client gửi yêu cầu ATM ARP khác.

ATM switch router có thể được cấu hình như ATM ARP client để làm việc với một vài
ATM ARP server theo RFC 1577. Sự lựa chọn một trong những ATM switch router trong
một LIS (logical IP subnet) có thể được cấu hình để hoạt động như ATM ARP server.
Trong trường hợp này, nó tự động hoạt động tốt như một client. Để cấu hình classical IP
và ARP trong một môi trường SVC cần thực hiện một trong những nhiệm vụ sau:

Cấu hình một ATM ARP client

Cấu hình một ATM ARP server

IV.1.1. CẤU HÌNH MỘT ATM ARP CLIENT

Trong một môi trường SVC, việc cấu hình cơ chế ATM ARP trên giao diện bằng cách
thực hiện những nhiệm vụ sau, bắt đầu trong mô hình cấu hình Global:

Step Command Task

1 interface atm0 Lựa chọn giao diện để cấu hình
2 atm nsap-address nsap- Chỉ định địa chỉ NSAP ATM của giao diện hoặc chỉ định
address địa chỉ ESI (end-system-identifier) của giao diện
 or

atm esi-address
esi.selector
3 ip address ip-address Chỉ định địa chỉ IP của giao diện
mask
4 atm arp-server nsap Chỉ định địa chỉ ATM của ATM ARP server
nsap-address
5 exit Thoát khỏi giao diện cấu hình
1
6 atm route {addr-prefix } Cấu hình định tuyến tĩnh thong qua ATM switch router tới
atm0 internal giao diện xử lí định tuyến. Xem những chú ý sau
1
First 19 bytes of the NSAP address.
Chú ý: Mẫu địa chỉ ESI ( end system identifier) được ưu tiên hơn trong việc nó điều
khiển địa chỉ quảng bá một cách tự động . Sử dụng mẫu NSAP của lệnh khi bạn cần định
nghĩa một địa chỉ đầy đủ 20 byte duy nhất với một tiền tố không liên quan tới tiền tố
mạng trên giao diện. Bạn chỉ cần chỉ rõ một định tuyến tĩnh khi cấu hình một ARP client
sử dụng địa chỉ NSAP.

Ví dụ về địa chỉ NSAP

The following example shows how to configure the route processor interface atm0 of
client A, in Figure 12-1, using the NSAP address:

Ví dụ sau chỉ rõ cách cấu hình giao diện xử lý định tuyến atm0 của client A trong hình
12-1, sử dụng địa chỉ NSAP:

Client A(config)# interface atm0

Client A(config-if)# atm nsap-address
47.0091.8100.0000.1111.1111.1111.1111.1111.1111.00
Client A(config-if)# ip address 123.233.45.1 255.255.255.0
Client A(config-if)# atm arp-server nsap
47.0091.8100.0000.1111.1111.1111.2222.2222.2222.00
Client A(config-if)# exit
Client A(config)# atm route
47.0091.8100.0000.1111.1111.1111.1111.1111.1111 atm0
internal

Ví dụ về ESI

Ví dụ sau chỉ rõ cách cấu hình bộ giao diện xử lý định tuyến atm0 của client A sử dụng
ESI (hình 12-1)

Client A(config)# interface atm0

Client A(config-if)# atm esi-address 0041.0b0a.1081.40
Client A(config-if)# ip address 123.233.45.1 255.255.255.0
Client A(config-if)# atm arp-server nsap
47.0091.8100.0000.1111.1111.1111.2222.2222.2222.00
 Client A(config-if)# exit

IV.1.2. CẤU HÌNH MỘT ATM ARP SERVER

Việc thực thi ATM ARP server của cisco hỗ trợ một server riêng lẻ không dư thừa trên
mỗi LIS và một ATM ARP server trên giao diện con. Do đó, một ATM switch router riêng
lẻ có thể hỗ trợ nhiều ARP server bằng cách sử dụng nhiều giao diện.

Để cấu hình một ATM ARP server phải hoàn thành những nhiệm vụ sau, bắt đầu trong
mô hình cấu hình Global

Step Command Task

1 interface
atm0[.subinterface#]
2 atm nsap-address nsap-
address
or
atm esi-address esi.selector
4 ip address ip-address mask
5 atm arp-server time-out
minutes1
6 atm route {addr-prefix2}
atm0 internal
Lựa chọn giao diện cấu hình
Specify the NSAP ATM address of the interface.
or
Chỉ rõ địa chỉ NSAP ATM của giao diện hoặc chỉ rõ
địa chỉ ESI (end-system-identifier) của giao diện.
Chỉ rõ địa chỉ IP của giao diện
Cấu hình tuỳ chọn thời gian rãnh cảu ATM ARP
server
Cấu hình một định tuyến tĩnh thông qua ATM switch
router tới giao diện xử lý định tuyến. Xem chú ý sau

Dạng lệnh ATP ARP server này cho biết giao diện này thực hiện những chức năng của
ATM ARP server. Khi bạn cấu hình ATM ARP client, lệnh ATM ARP server được sử
dụng với những từ khoá và đối số khác nhau để xác định một ATM ARP server khác tới
client.
Chú ý: Dạng địa chỉ ESI được ưu tiên hơn trong việc điều khiển địa chỉ quảng bá một
cách tự động. Sử dụng dạng lệnh NSAP khi bạn cần định nghĩa một địa chỉ 20 byte duy
nhất với tiền tố không liên quan tới tiền tố của mạng trên giao diện đó. Bạn chỉ cần chỉ rõ
một định tuyến tĩnh khi cấu hình một ARP server sử dụng một địa chỉ NSAP.
Khoảng thời gian rãnh rỗi là số phút mà đích đi vào được liệt kê trong bảng ARP của
ARP server có thể rãnh trước khi server thực hiện nhiều hoạt động tới thời gian đi vào kết
thúc.

Ví dụ:

Ví dụ sau chỉ rõ cấu hình giao diện xử lý định tuyến atm0 như một ARP server
( hình 12-1)

ARP_Server(config)# interface atm0

ARP_Server(config-if)# atm esi-address 0041.0b0a.1081.00
ARP_Server(config-if)# atm arp-server self
ARP_Server(config-if)# ip address 123.233.45.2 255.255.255.0

Display the IP-Over-ATM Interface Configuration

Hiển thị việc cấu hình giao diện IP over ATM
Để cấu hình ta sử dụng các lệnh sau:
Command Task
show atm arp-server Hiện thị cấu hình giao diện ATM ARP
show atm map Show the ATM map list configuration.

Examples

In the following example, the show atm arp-server command displays the configuration
of the interface atm0:

Switch# show atm arp-server

Note that a '*' next to an IP address indicates an active call

IP Address TTL ATM Address

ATM2/0/0:
* 10.0.0.5 19:21 4700918100567000000000112200410b0a108140

The following example displays the map-list configuration of the static map and IP-over-
ATM interfaces:

Switch# show atm map

Map list ATM2/0/0_ATM_ARP : DYNAMIC
arp maps to NSAP 36.0091810000000003D5607900.0003D5607900.00
, connection up, VPI=0 VCI=73, ATM2/0/0
ip 5.1.1.98 maps to s 36.0091810000000003D5607900.0003D5607900.00
, broadcast, connection up, VPI=0 VCI=77, ATM2/0/0

Map list ip : PERMANENT

ip 5.1.1.99 maps to VPI=0 VCI=200

IV.2. CẤU HÌNH CLIP TRONG MÔI TRƯỜNG PVC(permanent virtual circuit)

This section describes how you configure classical IP over ATM in a PVC environment.
The ATM Inverse ARP mechanism is applicable to networks that use PVCs, where
connections are established but the network addresses of the remote ends are not known.
A server function is not used in this mode of operation.

In a PVC environment, configure the ATM Inverse ARP mechanism by performing the
following tasks:
Step Command Task
1 interface atm0 Select the interface to be configured.
2 ip address ip-address mask Specify the IP address of the interface.
1
3 atm pvc vpi vci encap aal5snap [inarp Create a PVC and enable Inverse ARP
minutes] on it.
1
The VPI value on interface atm0 must always be 0.

Repeat these tasks for each PVC you want to create.

The inarp minutes interval specifies how often Inverse ARP datagrams are sent on this
virtual circuit. The default value is 15 minutes.

Note The ATM ARP and Inverse ATM ARP mechanisms work with IP only. All other
protocols require map-list command entries to operate.

Example

The following example shows how to configure an IP-over-ATM interface on interface

atm0, using a PVC with AAL5SNAP encapsulation, inverse ARP set to ten minutes, VPI
= 0, and VCI = 100:

Switch(config)# interface atm0

Switch(config)# ip address 11.11.11.11
Switch(config-if)# atm pvc 0 100 encap aal5snap inarp 10 interface atm
0/0/0 50 100

Display the IP-Over-ATM Interface Configuration

To show the IP-over-ATM interface configuration, use the following command:

Command Task
show atm map Show the ATM interface ARP configuration.

Example

The following example displays the map-list configuration of the static map and IP over
ATM interfaces:

Switch# show atm map

Map list yyy : PERMANENT
ip 1.1.1.2 maps to VPI=0 VCI=200

Map list zzz : PERMANENT

Map list a : PERMANENT

Map list 1 : PERMANENT

Map list ATM2/0/0_ATM_ARP : DYNAMIC

arp maps to NSAP 47.009181005670000000001122.00410B0A1081.40
, connection up, VPI=0 VCI=85, ATM2/0/0
ip 10.0.0.5 maps to NSAP 47.009181005670000000001122.00410B0A1081.40
, broadcast, ATM2/0/0