RFC 730
Genişletilebilir Alan Adresleme
20 Mayıs 1977
Network Working Group — Jon Postel
Request for Comments: 730 — USC-ISI
NIC: 40400
Giriş
Bu not, bir ağ ortamında adreslerin alanlar kümesi olarak ifade edilmesinin gerekliliğini ve avantajlarını ele almaktadır. Öneri, ağ büyüdükçe adresin üç teknikle genişletilebileceğidir: sola alan eklemek, sağa alan eklemek ve tek tek alanların boyutunu artırmak. Carl Sunshine, kaynak yönlendirme üzerine yazdığı bir makalede bu tür adreslemeyi tanımlamıştır [1].
Gerekçe
Host-IMP Arayüzündeki Değişiklik
Gözden geçirilmiş Host-IMP arayüzü, hostlar ve IMP’ler için daha geniş bir adres alanı sağlar [2]. Eski arayüz, 2 bitlik bir host alanına ve 6 bitlik bir IMP alanına izin veriyordu. Yeni arayüz ise 8 bitlik bir host alanına ve 16 bitlik bir IMP alanına izin vermektedir. Eski arayüz kullanılırken, bu iki alanı tek bir sekiz bitlik nicelik olarak ele almak yaygın bir uygulamaydı. Bir hosta numara ile atıfta bulunmak gerektiğinde sıklıkla ondalık bir sayı kullanılırdı. Örneğin IMP 1 üzerindeki host 1, host 65 olarak adlandırılırdı. Doug Wells, yeni arayüz kullanıma girdiğinde bu tür bir kullanımın sürdürülmeye çalışılmasıyla ilişkili bazı sorunlara dikkat çekmiştir [3]. Alan başına bir gösterim kullanılmış olsaydı hiçbir sorun ortaya çıkmazdı.
Eski ve yeni host numaralarına bazı örnekler aşağıdadır:
| Host Adı | Host | IMP | Eski # | Yeni # |
|---|---|---|---|---|
| SRI-ARC | 0 | 2 | 2 | 2 |
| UCLA-CCN | 1 | 1 | 65 | 65537 |
| ISIA | 1 | 22 | 86 | 65558 |
| ARPA-TIP | 2 | 28 | 156 | 131100 |
| BBNA | 3 | 5 | 197 | 196613 |
Çoklu Ağ Sistemleri
Ağların birbirine bağlanarak karmaşık bir çoklu ağ sistemi oluşturma olasılığı, ek adresleme sorunlarını da beraberinde getirmektedir. Yeni Host-IMP arayüzü belirtimi, lider içinde ağ adreslerini taşımak üzere alanlar ayırmıştır [2]. Ağların birbirine bağlanmasına yönelik deneysel çalışmalar devam etmektedir [4, 5, 6]. Adres alanındaki bu genişlemelere hazır olmalıyız.
Adresleme şeması, karmaşık sistemler arasında bağlantılar kurulduğunda kapsamını artırabilecek şekilde genişletilebilir olmalıdır.
Çok İşlemcili Hostlar
Bir ağa tek bir host olarak bağlanabilecek, ancak gerçekte birden fazla işlemci içeren donanım yapılandırmaları olabilir. Görevler işlemcilerle ilişkilendirilebilir; böylece belirli soketler veya mesaj tanımlayıcılarıyla ilişkili ağ mesajlarının belirli işlemcilere yönlendirilmesi arzu edilebilir. Örneğin tüm Telnet kullanımının bir işlemci tarafından, tüm FTP kullanımının ise farklı bir işlemci tarafından karşılanması istenebilir.
Adresleme şeması, istendiğinde bir host içindeki ince yapıyı açıkça adresleyebilecek şekilde genişletilebilir olmalıdır.
ARPANET’te bu tür ince yapı adreslemenin yararlı olabileceği bazı örnekler şunlardır:
ISI’de, PRIM sistemi kullanılarak bilgisayarların benzetimini yapabilme yeteneğine sahibiz [7]. Birçok uygulama için, benzetimi yapılan hostun ağa eklenmesi arzu edilir. Benzetim, Tenex altında çalışan bir programın denetimi altında gerçekleştirildiğinden, bir host içinde bir host söz konusudur. Hostların genişletilebilir adreslenmesi gerekli tutamacı sağlayacaktır.
SCRL’de bir zamanlar UCSB’deki bir IMP’ye VDH ile bağlı bir PDP-11 vardı. Daha sonra ağa ikinci bir PDP-11 eklemek gerekli hale geldi. İki PDP-11 zaten fiziksel olarak bağlıydı ve ilkinin her ikisi için de çoklayıcı olarak hizmet vermesi basit bir iş olurdu. Ancak ağ adresleme yapısındaki sınırlamalar nedeniyle, iki hostu ağ üzerindeki diğer sitelere tanıtmanın bir yolu yoktu. Yeni bir IMP kurulmak zorunda kaldı!
Diğer birçok durumda, iki hostun ağ için aynı ön ucu paylaşması arzu edilir. Mevcut sınırlama ile her host için bir IMP portu tüketilmek zorundadır.
Öneri
Host-IMP arayüzündeki değişikliğin ortaya çıkardığı soruna gerekli çözüm, adresin her zaman alanlar aracılığıyla temsil edilmesidir. Bu çözüm, bir ağlar arası ortama doğal bir büyümeyi sağlar ve istendiğinde bir host içindeki ince yapının açık adreslenmesine olanak tanır.
Alanlar doğal bir biçimde yazılmalıdır ve bunun, en genel alanın önce gelmesi, ardından adresin giderek daha fazla ayrıntısını belirten ek alanların gelmesi anlamına geldiğine inanıyorum. Mevcut durumda bu, aşağıdaki alanlara yol açacaktır:
Network / IMP / Host / Message-Identifier
Basit alan adreslemenin bir sorunu, yerel bağlam göz önüne alındığında yalnızca gerekli alanların belirtilmek istenmesidir. Adresi yorumlayan bir program, bu durumda ilk alanın neyi temsil ettiğinden emin olamaz. Doğru ayrıştırmanın mümkün olması için adres belirtiminde bazı ipuçlarına ihtiyaç vardır. Dave Crocker, verilerin ağ üzerinden erişiminde benzer bir sorun için bir sözdizimi tanımlamıştır [8].
Özel Öneri
Özel olarak, her alanın komşularından bir ayırıcı karakterle ayrıldığı ve her alanın bir ada sahip olduğu, alan tabanlı genişletilebilir bir adresleme şemasını benimsememizi öneriyorum. Bir adres belirtildiğinde, en genel alanın adının da belirtilmesi zorunludur.
Tanımlar:
<address> ::= <field-name> ":" <fields>
<field-name> ::= "NET" | "IMP" | "HOST" | "MESSAGE-ID"
<fields> ::= <field> | <field> "/" <fields>
<field> ::= ondalık bir sayı
Örnekler:
NET:1/3/5/7
Ağ 1’de, IMP 3 üzerindeki host 5’te bulunan mesaj-tanımlayıcı 7’yi adlandırır.
HOST:6
Bu mesajın kaynaklandığı IMP üzerinde bulunan host 6’yı adlandırır.
Şu soru sorulabilir: Bütün bu tantana neden, bu aslında bir sorun değil mi? Yanıt şudur: Neredeyse. Gerçek zorlukların ortaya çıktığı çok az yer vardır, ancak host adresleri hakkında düşünme biçimimizi değiştirmemiz gerekir. Sorunun olduğu yerler genellikle pek az kullanılır; bir istisna dışında. İnsanların zorluk yaşayacağı yer TIP “open” komutudur [9] ve daha az ölçüde kullanıcı Telnet ve kullanıcı FTP “connect” komutlarıdır. Diğer yerler MAIL netaddress alanı, FTP “sock” komutu [10], Telnet yeniden bağlanma seçeneği [11] ve NIC tarafından tutulan resmi host adları listesinde yer almaktadır [12].
Sonuç
Öneri, üç yönde büyümeyi sağlamak üzere alan tabanlı genişletilebilir adreslemeyi benimsememizdir:
- Host ve IMP sayısının, bu alanların birbirinden bağımsız olarak boyutlarının artırılmasına izin verilerek büyümesi;
- Çoklu ağ sistemlerini desteklemek üzere sola alanlar eklenerek kapsamın büyümesi;
- Hostların mini ağlar olarak gerçekleştirilmesi için sağa alanlar eklenerek ince yapının büyümesi.
Kaynaklar
Sunshine, C. "Source Routing and Computer Networks," Computer Communication Review, Cilt 7, Sayı 1, ACM Special Interest Group on Communications (SIGCOMM), Ocak 1977. Ayrıca INWG General Note numara 133 olarak dolaşıma sokulmuştur.
BBN, "The Interconnection of a Host and an IMP," Rapor 1822, Bolt Beranek and Newman, Ocak 1976’da gözden geçirilmiştir.
Wells, D., "Impact of New IMP Leaders on Higher-level Protocols," ARPA Network Message [MIT-Multics]1.2.BBBJGbHZPXdDjl, MIT, 19 Mayıs 1977.
Beeler, ve diğerleri, "Gateway Design for a Computer Network Interconnection," PRTN 156, Şubat 1976.
Cerf, V., Y. Dalal ve C. Sunshine, "Specification of an Internet Transmission Control Program," INWG General 72, RFC 675, Aralık 1974’te gözden geçirilmiştir.
Cerf, V., "Specification of TCP version 2," Mart 1977.
Britt, B., ve diğerleri, "PRIM System: Overview," ISI/RR-77-58, Information Sciences Institute, University of Southern California, Mart 1977.
Crocker, D., "Network Standard Data Specification Syntax," RFC 645, Network Information Center Katalog Numarası 30899, 27 Haziran 1974.
Malman, J., "User's Guide to the Terminal IMP," Rapor 2138, Bolt Beranek and Newman, Network Information Center Katalog Numarası 10916, Mart 1976’da gözden geçirilmiştir.
Neigus, N., "File Transfer Protocol," RFC 542, Network Information Center Katalog Numarası 17759, 12 Ağustos 1973. ARPANET Protocol Handbook içinde yer almaktadır, Network Information Center Katalog Numarası 7104, 1 Nisan 1976’da gözden geçirilmiştir.
Thomas, R., "Telnet Reconnection Option," Network Information Center Katalog Numarası 15391, Ağustos 1973. ARPANET Protocol Handbook içinde yer almaktadır, Network Information Center Katalog Numarası 7104, 1 Nisan 1976’da gözden geçirilmiştir.
[Office-1]
HOSTS.TXT